[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-4471 to WFCORE-629:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-629 (was: WFLY-4471)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
> Enabled automatic encryption of passwords stored in configuration
> -----------------------------------------------------------------
>
> Key: WFCORE-629
> URL: https://issues.jboss.org/browse/WFCORE-629
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Environment: Wildfly 9
> Reporter: Jason Shepherd
>
> Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration.
> It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4471) Enabled automatic encryption of passwords stored in configuration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4471?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4471:
-----------------------------------
Component/s: Domain Management
Security
(was: ConfigAdmin)
> Enabled automatic encryption of passwords stored in configuration
> -----------------------------------------------------------------
>
> Key: WFLY-4471
> URL: https://issues.jboss.org/browse/WFLY-4471
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Security
> Environment: Wildfly 9
> Reporter: Jason Shepherd
> Assignee: Thomas Diesler
>
> Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration.
> It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4477) deployment runtime-name mismatch between content repo and server-group and logs
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4477?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-4477:
--------------------------------------
Assignee: ehsavoie Hugonnet (was: Jason Greene)
Component/s: Domain Management
I'm assigning this to the Domain Management component under the assumption that the console is just displaying what the server side management model provides.
Emmanuel, if this is still an issue with core master, please move this over to WFCORE JIRA.
> deployment runtime-name mismatch between content repo and server-group and logs
> -------------------------------------------------------------------------------
>
> Key: WFLY-4477
> URL: https://issues.jboss.org/browse/WFLY-4477
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Ian Kent
> Assignee: ehsavoie Hugonnet
> Attachments: Screen Shot 2015-03-31 at 12.49.20 PM.png, Screen Shot 2015-03-31 at 12.49.45 PM.png
>
>
> We are continuously deploying web applications (wars) into our wildfly domain as part of our continuous deployment driven by Bamboo.
> Each time an application build succeeds it will trigger a deployment to our wildfly domain.
> If this is the first deployment we run this command.
> {noformat}
> jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\
> SHOT-b1.war --server-groups=A
> {noformat}
> For subsequent deployments we force a redeploy over existing deployment.
> {noformat}
> jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\
> SHOT-b2.war --force
> jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\
> SHOT-b3.war --force
> jboss-cli.sh --connect --controller=somehost:9990 --user=admin --password=admin --command="deploy app-0.1-SNAPSHOT.war --name=app.war --runtime-name=app-0.1-SNAP\
> SHOT-b4.war --force
> etc....
> {noformat}
> Since upgrading to WildFly 8.2.0 we see a strange behaviour in the domain management web console (http://somehost:9990/console/App.html#domain-deployments).
> The application runtime name in content repository is not the same as what is shown in the server group.
> I will attach screenshots for an app named apollo.war. You will see from the screenshots that the content repository shows runtime name=apollo-0.1.12-SNAPSHOT-11\
> 03.war, but the
> server group shows runtime-name=apollo-0.1.12-SNAPSHOT-1045.war. (The last number in runtime-name is the build number from bamboo)
> The server.logs from wildfly show "Deployed "apollo.war" (runtime-name : "apollo-0.1.12-SNAPSHOT-1045.war")"
> However, we can tell by app capabilities that what is really deployed is apollo-0.1.12-SNAPSHOT-1103.war.
> We are totally confused by this discrepency.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[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:
-----------------------------------
We will not fix this to be exactly how it was before, because the way we assemble modules makes this difficult/impractical. Both the old and new behavior comply with the Java EE spec.
If you want to compose a module from multiple JARs, you should either fix packaging to assemble the JARs appropriately, use deployment overlays, and/or use jboss-deployment-structure.xml to use a customized module assembly, or some combination of the these options. But, this is an appropriate discussion for the forums, not the bug tracker.
> 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
[JBoss JIRA] (WFCORE-628) Support for 'query' operation on legacy slaves
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-628?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-628:
-----------------------------------------
Harald, WFCORE-628 is the promised JIRA for the mixed domain stuff we chatted about last Thursday.
> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
> Key: WFCORE-628
> URL: https://issues.jboss.org/browse/WFCORE-628
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-628) Support for 'query' operation on legacy slaves
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-628:
---------------------------------------
Summary: Support for 'query' operation on legacy slaves
Key: WFCORE-628
URL: https://issues.jboss.org/browse/WFCORE-628
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 2.0.0.Beta1
WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
There may of course be gotchas there.
One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated REMJMX-94:
-----------------------------------
Fix Version/s: 2.0.1.Final
(was: 2.0.1.CR2)
> Memory leak in remoting-jmx
> ---------------------------
>
> Key: REMJMX-94
> URL: https://issues.jboss.org/browse/REMJMX-94
> Project: Remoting JMX
> Issue Type: Bug
> Affects Versions: 1.1.3.Final
> Reporter: Libor Zoubek
> Assignee: Darran Lofthouse
> Labels: memory_leak
> Fix For: 2.0.1.Final
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
> I am not sure if memleak is in remoting-jmx or some other underlying stuff.
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on REMJMX-94:
----------------------------------------
[~dmlloyd] Might need to run this one by you - debugging this myself with the XNIO version currently used in WildFly (And Core) I am still seeing the same behaviour that Brad describes with the classloaders being kept around with references leading back to ThreadLocalCache of ByteBufferSlicePool.
Within Remoting JMX I have double checked and there are no remaining places that I fail to clean up resources that I created so not sure if there is anything else I can do to clean this up myself.
I do have a heap dump after modifying the test case if you want.
> Memory leak in remoting-jmx
> ---------------------------
>
> Key: REMJMX-94
> URL: https://issues.jboss.org/browse/REMJMX-94
> Project: Remoting JMX
> Issue Type: Bug
> Affects Versions: 1.1.3.Final
> Reporter: Libor Zoubek
> Assignee: Darran Lofthouse
> Labels: memory_leak
> Fix For: 2.0.1.CR2
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
> I am not sure if memleak is in remoting-jmx or some other underlying stuff.
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues
by Anindhya Sharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ]
Anindhya Sharma commented on WFLY-4374:
---------------------------------------
David,
We have supported multiple Java Application servers (and continue to do so) over the years and multiple versions of them. WebSphere, WebLogic and JBoss. In all the versions of all these products (JBoss included) we have never had this issue using the Class-Path entry in manifest file, even for the same class in different jar files. We have supported Jboss 4, 5, 6 and 7, the last one being 7.2.0.Final. Are you saying that the issue is due to how the implementation has been done in Jboss modules that is causing the issue and that the implementation in Wildfly honors the Java EE spec and hence you will not fix this? Trying to understand why this was changed in Wildfly when all other application servers in multiple versions honor this scheme? Is it because the Java EE spec changed or because that is how Jboss modules are implemented?
Given that all previous versions of Jboss have worked like mentioned in the issue (and other products still support it), would you be able to help point out specific of the Java EE specification that caused this changed in how Wildfly is working? Again trying to understand whether Wildfly just fixed an issue that was there in previous versions of Jboss and other vendor products...?
Thanks!
> 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