April 2015 - jboss-jira - Jboss List Archives

[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 commented on WFLY-4374: ----------------------------------- You cannot split packages across JARs due to modularity rules. That'll be the cause of your #3 error. The other two sound like questions for the user 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-470) support patching through the http mgmt API

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-470?page=com.atlassian.jira.plugin... ] Kabir Khan commented on WFCORE-470: ----------------------------------- I am planning/hoping to revisit the HTTP management API over the next few months to make it more RESTful. A side effect of that work might be that this task becomes simpler. > support patching through the http mgmt API > ------------------------------------------ > > Key: WFCORE-470 > URL: https://issues.jboss.org/browse/WFCORE-470 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching > Affects Versions: 1.0.0.Alpha1 > Reporter: Emanuel Muckenhuber > Fix For: 2.0.0.Beta1 > > > The patch operation requires an input stream attachment of the patch content, which is not generally supported for all operations of the http API. We probably need to do something similar to the deployment add-content handler. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-429: ------------------------------------ Fix Version/s: (was: 1.0.0.CR1) > Incremental redeployment (single file update) over management API > ----------------------------------------------------------------- > > Key: WFCORE-429 > URL: https://issues.jboss.org/browse/WFCORE-429 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Ondrej Zizka > Labels: deploy, deployment, incremental, redeployment > > (Based on JBDS use case - see EAP6-1) > See also https://mojo.redhat.com/docs/DOC-934058 for notes > By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc. > Use cases: > Big .war's, mainly on remote > Cloud deployments > Also, you loose sessions etc. > "JSP recompile on file update" - mgmt API operation - added in WildFly 8? > Not expected to work in domain mode. > Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-310) Don't copy the contents to all hosts when assigning a deployment to a server-group

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-310?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-310: --------------------------------------- Fix Version/s: 2.0.0.CR1 (was: 1.0.0.CR1) Assignee: luck3y (was: Brian Stansberry) Ken, this is another one in the general area of slave host to master host interaction. See the bugzilla for a pretty thorough discussion. > Don't copy the contents to all hosts when assigning a deployment to a server-group > ---------------------------------------------------------------------------------- > > Key: WFCORE-310 > URL: https://issues.jboss.org/browse/WFCORE-310 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: luck3y > Fix For: 2.0.0.CR1 > > > When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-391) Add management API descriptions for alias resources and attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-391: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Add management API descriptions for alias resources and attributes > ------------------------------------------------------------------ > > Key: WFCORE-391 > URL: https://issues.jboss.org/browse/WFCORE-391 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 2.0.0.Beta1 > > > When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship. > For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-363: --------------------------------------- Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) Assignee: (was: Brian Stansberry) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFCORE-363 > URL: https://issues.jboss.org/browse/WFCORE-363 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 2.0.0.Beta1 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-470) support patching through the http mgmt API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-470?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-470: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > support patching through the http mgmt API > ------------------------------------------ > > Key: WFCORE-470 > URL: https://issues.jboss.org/browse/WFCORE-470 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching > Affects Versions: 1.0.0.Alpha1 > Reporter: Emanuel Muckenhuber > Fix For: 2.0.0.Beta1 > > > The patch operation requires an input stream attachment of the patch content, which is not generally supported for all operations of the http API. We probably need to do something similar to the deployment add-content handler. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-403) Evaluate making operation "composite" EntryType.PUBLIC

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-403?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-403: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Evaluate making operation "composite" EntryType.PUBLIC > ------------------------------------------------------ > > Key: WFCORE-403 > URL: https://issues.jboss.org/browse/WFCORE-403 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.Beta1 > > > When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it. > Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-395) Improve reporting during deployment hang

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-395?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-395: ------------------------------------ Fix Version/s: 2.0.0.CR1 (was: 1.0.0.CR1) > Improve reporting during deployment hang > ---------------------------------------- > > Key: WFCORE-395 > URL: https://issues.jboss.org/browse/WFCORE-395 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: http://java.net/jira/browse/EJB_SPEC-60 > java version "1.7.0_09" > OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > Ubuntu 12.10 > Reporter: Carlo de Wolf > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > Attachments: deployment-hang-20130205.txt, server.log > > > Management Thread waits indefinitely for, what seems to be, a finished operation. > {noformat} > "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at java.lang.Object.wait(Object.java:503) > at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158) > - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464) > at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-396: ----------------------------------------- If this slips to 2.0.0.Beta1 that's fine. Please reschedule it if you think that's likely. > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 1.0.0.CR1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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 April 2015