February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues

by John Sipher (JIRA)

[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ] John Sipher updated WFLY-4374: ------------------------------ Attachment: problem-demo.zip Contains source and war files needed to reproduce the issues > 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 > Environment: Windows 7/Java 7 update 67 > Reporter: John Sipher > Assignee: David Lloyd > Attachments: problem-demo.zip > > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues

by John Sipher (JIRA)

John Sipher created WFLY-4374: --------------------------------- Summary: 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 Environment: Windows 7/Java 7 update 67 Reporter: John Sipher Assignee: David Lloyd 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2480) Infinispan test XML files do not validate against XSD yet are parsed ok

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2480?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-2480: -------------------------------------- This will be the fix: https://github.com/rhusar/wildfly/compare/WFLY-2480_infinispan_xsd?expand=1 > Infinispan test XML files do not validate against XSD yet are parsed ok > ----------------------------------------------------------------------- > > Key: WFLY-2480 > URL: https://issues.jboss.org/browse/WFLY-2480 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > So one or the other should to change. > cvc-complex-type.2.4.a: Invalid content was found starting with element 'store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected. > cvc-complex-type.2.4.a: Invalid content was found starting with element 'mixed-keyed-jdbc-store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected. > cvc-complex-type.2.4.d: Invalid content was found starting with element 'binary-keyed-table'. No child element is expected at this point. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2480) Infinispan test XML files do not validate against XSD yet are parsed ok

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2480?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-2480: -------------------------------------- So this is a couple of issues together. They mostly come from the restrictions of XSD. {quote} The type has an 'all' model group in its \{content type\} and thus cannot be derived from a non-empty type, since this would produce a 'sequence' model group containing the 'all' model group; 'all' model groups are not allowed to appear inside other model groups.{quote} In short, the order needs to be forced if we want to continue using derived/extended types. So fixing ordering discrepancy between XSD and Writer: * state transfer in writer and test files * binary/string-keyed-table in xsd and * backup-for/backups XSD discrepancy: both can be actually used simultaneously ...and old schema test files ordering issues. > Infinispan test XML files do not validate against XSD yet are parsed ok > ----------------------------------------------------------------------- > > Key: WFLY-2480 > URL: https://issues.jboss.org/browse/WFLY-2480 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > So one or the other should to change. > cvc-complex-type.2.4.a: Invalid content was found starting with element 'store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected. > cvc-complex-type.2.4.a: Invalid content was found starting with element 'mixed-keyed-jdbc-store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected. > cvc-complex-type.2.4.d: Invalid content was found starting with element 'binary-keyed-table'. No child element is expected at this point. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2480) Infinispan test XML files do not validate against XSD yet are parsed ok

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2480?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-2480: --------------------------------- Priority: Major (was: Minor) > Infinispan test XML files do not validate against XSD yet are parsed ok > ----------------------------------------------------------------------- > > Key: WFLY-2480 > URL: https://issues.jboss.org/browse/WFLY-2480 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > So one or the other should to change. > cvc-complex-type.2.4.a: Invalid content was found starting with element 'store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected. > cvc-complex-type.2.4.a: Invalid content was found starting with element 'mixed-keyed-jdbc-store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected. > cvc-complex-type.2.4.d: Invalid content was found starting with element 'binary-keyed-table'. No child element is expected at this point. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-511) KieContainerImpl.updateResourcesIncrementally throws NullPointerException when a package doesn't exist

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-511?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-511: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1190903, https://bugzilla.redhat.com/show_bug.cgi?id=1194482 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1190903) > KieContainerImpl.updateResourcesIncrementally throws NullPointerException when a package doesn't exist > ------------------------------------------------------------------------------------------------------ > > Key: DROOLS-511 > URL: https://issues.jboss.org/browse/DROOLS-511 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Mike Wilson > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.CR1 > > > When calling KieContainerImpl.updateToVersion(ReleaseId), we sometimes experience a NullPointerException during a chained set of method calls that try to obtain a package, and then a rule within it. > If the package is null, a NullPointerException is thrown, because there is no check in place before that call to get the rule from the package. > To prevent this, a null check should be added to the package before trying to get the rule from it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-560) Incorrect wildcard handling in OperationContextImpl.getAuthorizationResource(PathAddress address)

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-560: --------------------------------------- Summary: Incorrect wildcard handling in OperationContextImpl.getAuthorizationResource(PathAddress address) Key: WFCORE-560 URL: https://issues.jboss.org/browse/WFCORE-560 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha18 Reporter: Brian Stansberry Assignee: Brian Stansberry Problem is 2nd and 3rd lines here: {code} if (element.isWildcard()) { model = Resource.Factory.create(); final Set<Resource.ResourceEntry> children = model.getChildren(element.getKey()); for (final Resource.ResourceEntry entry : children) { model.registerChild(entry.getPathElement(), entry); } } else { {code} Problem is "model" will have no children because it was just reassigned to a new Resource. The lines need to be swapped. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go updated WFLY-4373: ---------------------------- Description: The following snippet of code to redeploy an application: ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); ModelNode operation = new ModelNode(); operation.get("operation").set("redeploy"); operation.get("address").add("deployment", "server.war"); cl.execute(operation); cl.close(); - works fine, but .close() freezes forever. This issue depends to not only redeploy, but also for any other operations. was: The following snippet of code to redeploy an application: ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); ModelNode operation = new ModelNode(); operation.get("operation").set("redeploy"); operation.get("address").add("deployment", "server.war"); client.execute(operation); client.close(); - works fine, but .close() freezes forever. This issue depends to not only redeploy, but also for any other operations. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: CLI, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Alexey Loubyansky > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go updated WFLY-4373: ---------------------------- Description: The following snippet of code to redeploy an application: ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); ModelNode operation = new ModelNode(); operation.get("operation").set("redeploy"); operation.get("address").add("deployment", "server.war"); client.execute(operation); client.close(); - works fine, but .close() freezes forever. This issue depends to not only redeploy, but also for any other operations. was: The following snippet of code to redeploy an application: ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); ModelNode operation = new ModelNode(); operation.get("operation").set("redeploy"); operation.get("address").add("deployment", "server.war"); client.execute(operation); client.close(); - works fine, but .close() freezes forever. This issue depends to not only redeploy, but also for any other operations. > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: CLI, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Alexey Loubyansky > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > client.execute(operation); > client.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

Georgy Go created WFLY-4373: ------------------------------- Summary: WildFly CLI API ModelControllerClient memory leak? Key: WFLY-4373 URL: https://issues.jboss.org/browse/WFLY-4373 Project: WildFly Issue Type: Bug Components: CLI, IO Affects Versions: 8.2.0.Final Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final Reporter: Georgy Go Assignee: Alexey Loubyansky The following snippet of code to redeploy an application: ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); ModelNode operation = new ModelNode(); operation.get("operation").set("redeploy"); operation.get("address").add("deployment", "server.war"); client.execute(operation); client.close(); - works fine, but .close() freezes forever. This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015