[JBoss JIRA] (WFLY-4254) Symbolic links within web applications do not work
by Kris Iyer (JIRA)
[ https://issues.jboss.org/browse/WFLY-4254?page=com.atlassian.jira.plugin.... ]
Kris Iyer commented on WFLY-4254:
---------------------------------
The defects you refer to as being rejected earlier are against AS7.0, and 7.1.1 which had known issues. This is also supported under AS 7.4 - EAP 6.3. The schema supports this as part of web metadata, but not respected by the web container. I recommend that we do not reject this based off AS7-3357 that was rejected 2 years ago, and then a fix comes up in EAP 6.1.0.Alpha (7.2.0.Final). On a related note, supporting symbolic links is useful for exploded content and scaling deployments in the cloud, where bind mounts are not always easy to work with and automate and often times error prone.
> Symbolic links within web applications do not work
> --------------------------------------------------
>
> Key: WFLY-4254
> URL: https://issues.jboss.org/browse/WFLY-4254
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Kris Iyer
> Assignee: Bartosz Baranowski
>
> Symbolic Linking under exploded web-apps to files and/or directories outside the web-app do not work.
> Here is what I tried under an exploded war:
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd"
> version="8.0">
> <symbolic-linking-enabled>true</symbolic-linking-enabled>
> </jboss-web>
> Does not follow links and results in a 404.
> HTTP/?.? 404 Not Found
> Connection: keep-alive
> X-Powered-By: Undertow/1
> Server: WildFly/8
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4258) change BootStrapContextService dependency on WorkManagerService from OPTIONAL to REQUIRED
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-4258:
---------------------------------------
Summary: change BootStrapContextService dependency on WorkManagerService from OPTIONAL to REQUIRED
Key: WFLY-4258
URL: https://issues.jboss.org/browse/WFLY-4258
Project: WildFly
Issue Type: Task
Components: JCA
Affects Versions: 9.0.0.Alpha1
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
In connector/src/main/java/org/jboss/as/connector/subsystems/jca/BootstrapContextAdd.java the dependecy type specified is OPTIONAL, which deprecated and discouraged.
In addition, this dependency may cause failures during the boot if bootstrap context is added to management model before the workmanager (which is what happens during the testing of the filesystem tree based model persistence where the order of resources is not generally enforced).
Changing the dependency type to REQUIRED fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-329:
------------------------------------------------
Kris Verlaenen <kverlaen(a)redhat.com> changed the Status of [bug 1078146|https://bugzilla.redhat.com/show_bug.cgi?id=1078146] from ASSIGNED to MODIFIED
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.2.0.Final
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4257) EJB: Modify service granularity
by David Lloyd (JIRA)
David Lloyd created WFLY-4257:
---------------------------------
Summary: EJB: Modify service granularity
Key: WFLY-4257
URL: https://issues.jboss.org/browse/WFLY-4257
Project: WildFly
Issue Type: Task
Components: EE, EJB
Reporter: David Lloyd
This actually applies to components in general.
The granularity of EJB services is more fine-grained than is necessary. There is essentially a lock-step startup requirement within an application module no matter what, so it doesn't make sense to have services for every EJB; instead there could be one all-EJBs service chain, with aliases to satisfy external dependencies if needed, and that one service chain could internally perform all startup tasks concurrently. This should be much more scalable since the dependency graph of many-EJB deployments currently has a substantial overhead. It may also facilitate simpler embeddability.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-507) Unit test FileSystemDeploymentServiceUnitTestCase fails on IBM JDK
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-507?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet updated WFCORE-507:
-------------------------------------
Description:
Description of problem:
org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with:
- java.net.ConnectException: Connection refused
- java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
Version-Release number of selected component (if applicable):
EAP 6.4.0.ER1
How reproducible:
Always on IBM JDK
Steps to Reproduce:
1. ./build.sh -pl deployment-scanner -am -Dtest=FileSystemDeploymentServiceUnitTestCase -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -DfailIfNoTests=false
Actual results:
java.net.ConnectException: Connection refused
java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
java.lang.reflect.InvocationTargetException
Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment
was:
Description of problem:
org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with:
- java.net.ConnectException: Connection refused
- java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
Version-Release number of selected component (if applicable):
EAP 6.4.0.ER1
How reproducible:
Always on IBM JDK
Steps to Reproduce:
1. ./build.sh -pl deployment-scanner -am -Dtest=FileSystemDeploymentServiceUnitTestCase -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -DfailIfNoTests=false
Actual results:
java.net.ConnectException: Connection refused
java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
java.lang.reflect.InvocationTargetException
Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment
Expected results:
No failures in test case.
> Unit test FileSystemDeploymentServiceUnitTestCase fails on IBM JDK
> --------------------------------------------------------------------
>
> Key: WFCORE-507
> URL: https://issues.jboss.org/browse/WFCORE-507
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 1.0.0.Alpha15
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Trivial
>
> Description of problem:
> org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with:
> - java.net.ConnectException: Connection refused
> - java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
> Version-Release number of selected component (if applicable):
> EAP 6.4.0.ER1
> How reproducible:
> Always on IBM JDK
> Steps to Reproduce:
> 1. ./build.sh -pl deployment-scanner -am -Dtest=FileSystemDeploymentServiceUnitTestCase -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -DfailIfNoTests=false
> Actual results:
> java.net.ConnectException: Connection refused
> java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
> java.lang.reflect.InvocationTargetException
> Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-507) Unit test FileSystemDeploymentServiceUnitTestCase fails on IBM JDK
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-507?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet updated WFCORE-507:
-------------------------------------
Description:
org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with:
- java.net.ConnectException: Connection refused
- java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
Version-Release number of selected component (if applicable):
EAP 6.4.0.ER1
How reproducible:
Always on IBM JDK
Steps to Reproduce:
1. ./build.sh -pl deployment-scanner -am -Dtest=FileSystemDeploymentServiceUnitTestCase -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -DfailIfNoTests=false
Actual results:
java.net.ConnectException: Connection refused
java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
java.lang.reflect.InvocationTargetException
Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment
was:
Description of problem:
org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with:
- java.net.ConnectException: Connection refused
- java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
Version-Release number of selected component (if applicable):
EAP 6.4.0.ER1
How reproducible:
Always on IBM JDK
Steps to Reproduce:
1. ./build.sh -pl deployment-scanner -am -Dtest=FileSystemDeploymentServiceUnitTestCase -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -DfailIfNoTests=false
Actual results:
java.net.ConnectException: Connection refused
java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
java.lang.reflect.InvocationTargetException
Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment
> Unit test FileSystemDeploymentServiceUnitTestCase fails on IBM JDK
> --------------------------------------------------------------------
>
> Key: WFCORE-507
> URL: https://issues.jboss.org/browse/WFCORE-507
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 1.0.0.Alpha15
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Trivial
>
> org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment fails with:
> - java.net.ConnectException: Connection refused
> - java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
> Version-Release number of selected component (if applicable):
> EAP 6.4.0.ER1
> How reproducible:
> Always on IBM JDK
> Steps to Reproduce:
> 1. ./build.sh -pl deployment-scanner -am -Dtest=FileSystemDeploymentServiceUnitTestCase -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -DfailIfNoTests=false
> Actual results:
> java.net.ConnectException: Connection refused
> java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment
> java.lang.reflect.InvocationTargetException
> Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months