[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-4374.
-------------------------------
Resolution: Rejected
Discussion may be resumed on the forums.
> java.lang.IllegalAccessError and other classloader issues
> ---------------------------------------------------------
>
> Key: WFLY-4374
> URL: https://issues.jboss.org/browse/WFLY-4374
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Environment: Windows 7/Java 7 update 67
> Reporter: John Sipher
> Assignee: David Lloyd
> Attachments: problem-demo.zip
>
>
> Update 4/1/2015: I have verified that 9.0.0.Beta2 fixes the IllegalAccessError and the war file in problem-demo.zip/hello-world6/target now duplicates the original problem. The order of the jar files in the classpath should be
> WEB-INF/lib/patch/patch2.jar
> WEB-INF/lib/patch/patch1.jar
> WEB-INF/lib/base/helloworld-sans-cdi.jar
> org.jboss.as.quickstarts.helloworld.HelloService exists in both patch2.jar and helloworld-sans-cdi.jar. The version from patch2.jar should be used because it is first in the classpath, but the classloader is picking up the original class from helloworld-sans-cdi.jar instead.
> Original problem description follows:
> We use manifest-only jar files in our WAR and EAR files to control the order that jar files are searched for classes. When we issue patches, we put the modified class(es) in a separate jar file, add that jar file to the affected EAR or WAR file, and update the classpath in our manifest-only jar file to put the new patch at the beginning of the class path so that it will be used in place of the original class (which is still in the original jar file).
>
> For example, WEB-INF/lib will contain a single jar file named manifest.jar and sub-folders named 3rdparty, base, patch, and custom. The Class-Path entry in WEB-INF/lib/manifest.jar|META-INF/MANIFEST.MF looks like this:
> Class-Path: 3rdparty/manifest.jar patch/manifest.jar base/manifest.jar custom/manifest.jar
>
> When we publish a patch, the patch jar file is added to WEB-INF/lib/patch and to the front of the classpath in WEB-INF/lib/patch/manifest.jar's MANIFEST.MF.
>
> This worked fine for us for years with JBoss 4.2.3.GA, 5.1.0.GA, 7.1.2.Final, and 7.2.0.Final, but it's broken in WildFly 8.2.0.Final.
> When I run it in debug I can see where the problem shows up in this section of org.jboss.modules.Module (lines 562 - 573).
> final String path = pathOfClass(className);
> final Map<String, List<LocalLoader>> paths = getPathsUnchecked();
> final List<LocalLoader> loaders = paths.get(path);
> if (loaders != null) {
> Class<?> clazz;
> for (LocalLoader loader : loaders) {
> clazz = loader.loadClassLocal(className, resolve);
> if (clazz != null) {
> return clazz;
> }
> }
> }
> The modules in the loaders list at line 565 are
> * deployment.service.ear.lib/base/shared.jar:main
> * deployment.service.ear.lib/base/deployment.jar:main
> * deployment.service.ear.lib/patch/patch.jar:main
> The last one should actually be the first in the list. I haven't been able to track down the actual source of the error yet.
> I've been trying to create a simple example based on the helloworld quickstart to reproduce the problem, but I haven't been successful yet because of other classloader errors that I've run into. I decided to go ahead and open this issue and document the things I am able to reproduce. Those are:
> 1. CDI injection doesn't work when the annotated classes are in jar files under WEB-INF/lib instead of unpacked in WEB-INF/classes.
> 2. WildFly doesn't process the javax.servlet.annotation.WebServlet annotation if the jar file containing the annotated class is in a sub-folder of WEB-INF/lib.
> 3. WildFly throws a java.lang.IllegalAccessError trying to load a "patched" class.
> The first problem exists in both 7.2.0.Final and 8.2.0.Final. The other two problems are new in 8.2.0.Final.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-760) Code style formatters are not actual
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin... ]
Tibor Zimányi updated DROOLS-760:
---------------------------------
Description:
Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code.
There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs.
Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects.
was:
Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code.
There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs.
> Code style formatters are not actual
> ------------------------------------
>
> Key: DROOLS-760
> URL: https://issues.jboss.org/browse/DROOLS-760
> Project: Drools
> Issue Type: Task
> Reporter: Tibor Zimányi
> Assignee: Petr Široký
> Priority: Minor
> Attachments: code-styleQE.zip
>
>
> Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code.
> There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs.
> Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-760) Code style formatters are not actual
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin... ]
Tibor Zimányi updated DROOLS-760:
---------------------------------
Attachment: code-styleQE.zip
Attaching code style templates for IDEA and Eclipse that we use at QE.
> Code style formatters are not actual
> ------------------------------------
>
> Key: DROOLS-760
> URL: https://issues.jboss.org/browse/DROOLS-760
> Project: Drools
> Issue Type: Task
> Reporter: Tibor Zimányi
> Assignee: Petr Široký
> Priority: Minor
> Attachments: code-styleQE.zip
>
>
> Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code.
> There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-760) Code style formatters are not actual
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-760:
------------------------------------
Summary: Code style formatters are not actual
Key: DROOLS-760
URL: https://issues.jboss.org/browse/DROOLS-760
Project: Drools
Issue Type: Task
Reporter: Tibor Zimányi
Assignee: Petr Široký
Priority: Minor
Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code.
There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFLY-4339) NPE when deployment contains a *-ds.xml in domain
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-4339?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen reassigned WFLY-4339:
-------------------------------------
Assignee: Lin Gao (was: Stefano Maestri)
> NPE when deployment contains a *-ds.xml in domain
> -------------------------------------------------
>
> Key: WFLY-4339
> URL: https://issues.jboss.org/browse/WFLY-4339
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.2.0.Final
> Reporter: James Perkins
> Assignee: Lin Gao
> Fix For: 9.0.0.CR1
>
>
> If you build the [kitchen-sink quickstart|https://github.com/wildfly/quickstart/tree/master/kitchensink] and attempt to deploy to domain servers you'll see the following error. Same deployment works fine in standalone.
> {code}
> [Server:server-one] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-two] at java.lang.Thread.run(Thread.java:745)
> [Server:server-two] Caused by: java.lang.NullPointerException
> [Server:server-two] at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-two] ... 5 more
> [Server:server-two]
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] Caused by: java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-one] ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Tomaz Cerar edited comment on WFCORE-626 at 4/9/15 7:35 AM:
------------------------------------------------------------
Looking bit further into this, the fix that was done is not completely correct.
as *get-* operations should not invoke write-attribute afterwards and *should* be completely read-only and as such that extra "get" shouldn't matter.
I have it fixed locally as part of some other changes i am doing in same code.
was (Author: ctomc):
Looking bit further into this, the fix that was done is not completely correct.
as "get-*" operations should not invoke write-attribute afterwards and *should* be completely read-only and as such that extra "get" shouldn't matter.
I have it fixed locally as part of some other changes i am doing in same code.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-626:
------------------------------------
Looking bit further into this, the fix that was done is not completely correct.
as "get-*" operations should not invoke write-attribute afterwards and *should* be completely read-only and as such that extra "get" shouldn't matter.
I have it fixed locally as part of some other changes i am doing in same code.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years