[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-29:
----------------------------------------
Emanuel, since the PR is now merged, please make sure any JIRAS needed for further work are in place and then resolve this one.
> IllegalStateException when patching MBeans are queried during shutdown
> ----------------------------------------------------------------------
>
> Key: WFCORE-29
> URL: https://issues.jboss.org/browse/WFCORE-29
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Patching
> Reporter: James Livingston
> Assignee: Emanuel Muckenhuber
> Attachments: shutdownmbeanquery.jar
>
>
> If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null.
> This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised.
> java.lang.IllegalStateException
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-29:
-----------------------------------
Component/s: Patching
> IllegalStateException when patching MBeans are queried during shutdown
> ----------------------------------------------------------------------
>
> Key: WFCORE-29
> URL: https://issues.jboss.org/browse/WFCORE-29
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Patching
> Reporter: James Livingston
> Assignee: Emanuel Muckenhuber
> Attachments: shutdownmbeanquery.jar
>
>
> If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null.
> This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised.
> java.lang.IllegalStateException
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-3505 to WFCORE-29:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-29 (was: WFLY-3505)
Affects Version/s: (was: 8.1.0.Final)
Component/s: Domain Management
(was: Domain Management)
(was: JMX)
> IllegalStateException when patching MBeans are queried during shutdown
> ----------------------------------------------------------------------
>
> Key: WFCORE-29
> URL: https://issues.jboss.org/browse/WFCORE-29
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: James Livingston
> Assignee: Emanuel Muckenhuber
> Attachments: shutdownmbeanquery.jar
>
>
> If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null.
> This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised.
> java.lang.IllegalStateException
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-28) Add global resource notifications
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-28?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-3603 to WFCORE-28:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-28 (was: WFLY-3603)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Alpha4
(was: 9.0.0.CR1)
(was: 8.2.0.CR1)
> Add global resource notifications
> ---------------------------------
>
> Key: WFCORE-28
> URL: https://issues.jboss.org/browse/WFCORE-28
> Project: WildFly Core
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 1.0.0.Alpha4
>
>
> Emit notifications to any resource of WildFly management model:
> * resource-added - when a resource is added, it emits a resource-added notification
> * resource-removed - when a resource is removed, it emits a resource-removed notification
> * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information:
> * name - String - the name of the attribute
> * old-value - the detyped representation of the previous value of the attribute
> * new-value - the detyped representation of the new value
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3253) CXF should not be installing BouncyCastle
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3253?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-3253:
----------------------------------
Fix Version/s: (was: 9.0.0.Beta1)
> CXF should not be installing BouncyCastle
> -----------------------------------------
>
> Key: WFLY-3253
> URL: https://issues.jboss.org/browse/WFLY-3253
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Reporter: David Lloyd
> Assignee: Alessio Soldano
> Priority: Critical
>
> CXF installs a BouncyCastle provider globally into the security providers list. This is causes performance and other problems when this provider gets chosen for whatever reason to be the system crypto provider for e.g. TLS.
> The list of globally installed security providers should be a user concern only. If CXF requires a specific provider for a specific purpose, it should be selecting that provider when constructing the crytpo API object, though generally this is to be discouraged.
> Ultimately we want to introduce a configuration in the app server that allows the list of security providers to be specified in some way, without interference from any frameworks that we happen to have installed.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-27) Deployment scanner treats zipped content as unmanaged
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-27?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-3320 to WFCORE-27:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-27 (was: WFLY-3320)
Affects Version/s: (was: 8.0.0.Final)
(was: 8.1.0.CR1)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Alpha4
(was: 9.0.0.CR1)
> Deployment scanner treats zipped content as unmanaged
> -----------------------------------------------------
>
> Key: WFCORE-27
> URL: https://issues.jboss.org/browse/WFCORE-27
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Alpha4
>
>
> A really old commit[1] had the effect that both exploded and zipped deployments in the deployments/ dir are treated as unmanaged content. The original intent was zipped content should be uploaded to the content repo.
> This may be ok as I haven't heard about issues it causes. Emmanuel Hugonnet noted that there's an issue with JSP compilation work files from an deployment with a later timestamp not getting discarded if the scanner file has an older timestamp, but that is more an issue with how the JSP compilation work files are maintained than a problem with the scanner creating unmanaged deployments. Switching to managed deployments would fix that, but only for archives.
> [1] https://github.com/wildfly/wildfly/commit/fd2d9bc1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-26) Launcher API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-26?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFLY-2427 to WFCORE-26:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-26 (was: WFLY-2427)
Component/s: Server
(was: Server)
> Launcher API
> ------------
>
> Key: WFCORE-26
> URL: https://issues.jboss.org/browse/WFCORE-26
> Project: WildFly Core
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: James Perkins
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now.
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope.
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months