[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 commented on WFLY-4374:
-----------------------------------
More questions then:
1. Why did it work in previous versions like 7.2.0.Final?
2. Why does it not produce an IllegalAccessError in 9.0.0.Beta2?
3. Why does it work correctly if the package is split across two jars but not when it's split across three jars? This is true in both 8.2.0.Final and 9.0.0.Beta2. The only difference is that 9.0.0.Beta2 does not product the IllegalAccessError (it doesn't report an error, it just loads the wrong version of the class).
> 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-393) Clone a profile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-393:
---------------------------------------
Assignee: Kabir Khan
> Clone a profile
> ---------------
>
> Key: WFCORE-393
> URL: https://issues.jboss.org/browse/WFCORE-393
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 1.0.0.CR1
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Jason Greene commented on WFCORE-429:
-------------------------------------
FYI Per IM discussion with Max, he mentioned that the exploded type is essentially useless to him, so 204 was aimed (2)
> 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-107:
------------------------------------
Fix Version/s: 2.0.0.Alpha1
(was: 1.0.0.CR1)
> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
> Key: WFCORE-107
> URL: https://issues.jboss.org/browse/WFCORE-107
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 2.0.0.Alpha1
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-399) Domain Management - Support for database connection pool in non AS process.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ]
Darran Lofthouse edited comment on WFCORE-399 at 4/7/15 11:11 AM:
------------------------------------------------------------------
I would suggest closing either as deferred or out of date - I think really Kabir's subsystems in the HC work makes this obsolete. If we still have an issue then that is potentially a new issue anyway as this issue was raised on the basis there are absolutely no subsystems in the HC.
was (Author: dlofthouse):
I would suggest closing either as differed or out of date - I think really Kabir's subsystems in the HC work makes this obsolete. If we still have an issue then that is potentially a new issue anyway as this issue was raised on the basis there are absolutely no subsystems in the HC.
> Domain Management - Support for database connection pool in non AS process.
> ---------------------------------------------------------------------------
>
> Key: WFCORE-399
> URL: https://issues.jboss.org/browse/WFCORE-399
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
> These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
Jason Greene commented on WFCORE-429:
-------------------------------------
We should definitely sort out the requirements. We have 3 types of deployments:
1) Exploded - picked up by the file scanner (which hot redeploys), development only, and standalone mode only
2) Managed - deployed to standalone and domain mode, and stored in the content repository, indexed by the SHA of the deployment content
3) External - A reference in the configuration to an external file system location. This doesn't use the scanner, and it doesn't involve the content repository. It's usable in standalone and domain mode, and in both cases its the user's responsibility to copy the files over to all of the servers that reference it from the configuration.
One key requirement in EAP7-204, is that changes *must* survive a restart.
> 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)
9 years, 9 months
[JBoss JIRA] (WFCORE-399) Domain Management - Support for database connection pool in non AS process.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-399?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-399:
-----------------------------------------
I would suggest closing either as differed or out of date - I think really Kabir's subsystems in the HC work makes this obsolete. If we still have an issue then that is potentially a new issue anyway as this issue was raised on the basis there are absolutely no subsystems in the HC.
> Domain Management - Support for database connection pool in non AS process.
> ---------------------------------------------------------------------------
>
> Key: WFCORE-399
> URL: https://issues.jboss.org/browse/WFCORE-399
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
> These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required'
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-377:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> The management API should provide a command to restart only all servers that are in state 'reload-required'
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-377
> URL: https://issues.jboss.org/browse/WFCORE-377
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Wolf-Dieter Fink
> Labels: cli, domain, management
> Fix For: 2.0.0.Beta1
>
>
> After configuration changes via CLI batch it might be that different processes needs to be restarted.
> It is possible to iterate over all servers and check it.
> But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state
> - at domain level
> - at host level
> - at server level
> command example :
> :restart(ifRequired=true)
> :reload(ifRequired=true)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months