[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-4373:
--------------------------------------
Assignee: Tomaz Cerar (was: Brian Stansberry)
> WildFly CLI API ModelControllerClient memory leak?
> --------------------------------------------------
>
> Key: WFLY-4373
> URL: https://issues.jboss.org/browse/WFLY-4373
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, 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: Tomaz Cerar
> 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)
9 years, 9 months
[JBoss JIRA] (WFLY-4407) Upgrade wildfly-core to 1.0.0.Beta1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4407?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-4407.
------------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.CR1)
Resolution: Done
Please don't file these kinds of issues. Merging a PR in WildFly Core is sufficient to meet the "upstream" requirement for EAP. WildFly Core is the upstream for those portions of the EAP 6 codebase that are now maintained in WildFly Core.
> Upgrade wildfly-core to 1.0.0.Beta1
> -----------------------------------
>
> Key: WFLY-4407
> URL: https://issues.jboss.org/browse/WFLY-4407
> Project: WildFly
> Issue Type: Component Upgrade
> Affects Versions: 9.0.0.Alpha1
> Reporter: Bartosz Baranowski
> Assignee: Jason Greene
> Fix For: 9.0.0.Beta1
>
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4412) Not able to enable JMX Remote access
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4412?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4412:
-----------------------------------
Component/s: Domain Management
Logging
(was: ConfigAdmin)
> Not able to enable JMX Remote access
> ------------------------------------
>
> Key: WFLY-4412
> URL: https://issues.jboss.org/browse/WFLY-4412
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, Domain Management, Logging
> Affects Versions: 8.2.0.Final
> Environment: windows & linux
> Reporter: Shark Xu
> Assignee: David Lloyd
>
> Can not enable JMX remote access port.
> Config in domain.xml:
> <jvm-options>
> <option value="-Dcom.sun.management.jmxremote.port=19999"/>
> <option value="-Dcom.sun.management.jmxremote.authenticate=false"/>
> <option value="-Dcom.sun.management.jmxremote.ssl=false"/>
> </jvm-options>
> java.lang.IllegalStateException raised during startup.
> Logs:
> [Server:server-one] Exception in thread "main" java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util
> .logging.manager" system property to "org.jboss.logmanager.LogManager")
> [Server:server-one] at org.jboss.logmanager.Logger.getLogger(Logger.java:61)
> [Server:server-one] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:86)
> [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [Server:server-one] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:server-one] at java.lang.reflect.Method.invoke(Method.java:606)
> [Server:server-one] at org.jboss.modules.Module.run(Module.java:312)
> [Server:server-one] at org.jboss.modules.Main.main(Main.java:460)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[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 reassigned WFLY-4471:
--------------------------------------
Assignee: (was: Thomas Diesler)
> 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
>
> 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)
9 years, 9 months
[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)
9 years, 9 months
[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)
9 years, 9 months
[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)
9 years, 9 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:
-----------------------------------
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)
9 years, 9 months
[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)
9 years, 9 months
[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)
9 years, 9 months