[JBoss JIRA] (WFCORE-155) Evaluate robustness of decisions about target versions for transformation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-155?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-155:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Evaluate robustness of decisions about target versions for transformation
> -------------------------------------------------------------------------
>
> Key: WFCORE-155
> URL: https://issues.jboss.org/browse/WFCORE-155
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> Apologies; this is a bit vague, just a general thing I want us to look into.
> Task is to evaluate how we choose whether transformation needs to occur for a given management API version from a slave, with a view toward checking that intelligent choices are made in the absence of proper transformation definitions.
> The main kind of thing I'm thinking about is the DC is on 2.0.0 and has a transformer to 1.1.0 registered, and then a slave registers that is using 1.1.1. The subsystem author likely forgot to create the transformation to 1.1.1. Odds are good though that transforming to 1.1.0 is a better choice than not transforming and treating the slave as if it were on 2.0.0.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[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:
-----------------------------------
1. Because the class load order changed to be child-first.
2. Because the class load order changed to be child-first.
3. Because the class load order changed to be child-first, and it's only an actual error when a two classes in a split package try to access same-package resources that are package-private or otherwise are restricted to same-package access. In your two-JAR setup, such an access probably never occurs (or is not detectable).
> 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, 3 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-13:
-----------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 2.0.0.Beta1
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-370) Improve RBAC Performance
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-370?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-370:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
I'm deferring this to 2.0 as it's unclear to what degree this is a problem or where. Plus the existing subtasks are being deferred anyway. ;)
> Improve RBAC Performance
> ------------------------
>
> Key: WFCORE-370
> URL: https://issues.jboss.org/browse/WFCORE-370
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> Parent task for work related to reducing the impact of RBAC (WFLY-490) on management operation performance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-374) Rethink OperationContextImpl.getBasicAuthorizationResponse
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-374?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-374:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Rethink OperationContextImpl.getBasicAuthorizationResponse
> ----------------------------------------------------------
>
> Key: WFCORE-374
> URL: https://issues.jboss.org/browse/WFCORE-374
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> OperationContextImpl.getBasicAuthorizationResponse is designed around the "pass" case. It tests all action effects but discards data if any fail. This is ok in the normal case where things will pass. But in the read-resource-description and recursive read-resource cases, where things may often fail with the failure being recorded as expected (i.e. non-failure) output, this approach is inefficient, because the caller is forced to re-authorize to get the discarded data.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[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)
11 years, 3 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)
11 years, 3 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)
11 years, 3 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)
11 years, 3 months