[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet updated WFCORE-208:
-------------------------------------
Affects Version/s: 1.0.0.Alpha13
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha13
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet updated WFCORE-208:
-------------------------------------
Fix Version/s: 1.0.0.Alpha14
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha13
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Alpha14, 1.0.0.Beta1
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet updated WFCORE-208:
-------------------------------------
Fix Version/s: (was: 1.0.0.Beta1)
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha13
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Alpha14
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4008) MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-4008?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-4008:
---------------------------------
I have sent a PR https://github.com/wildfly/wildfly-core/pull/380 to fix it and [~swd847] can you take a look ? Also it looks like the similar issue in the wildfly/sar/src/main/java/org/jboss/as/service/AbstractService.java, I has a fix https://github.com/zhfeng/jboss-as/commit/38fdb8fa9b9a20e5b6e106a23fc528b...
Thanks a lot!
> MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4008
> URL: https://issues.jboss.org/browse/WFLY-4008
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMX, Naming
> Affects Versions: 8.1.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
> Labels: mbean
>
> If you create an MBean in your EJB and deploy the EJB.
> <pre>
> @SuppressWarnings("serial")
> public class Monitor implements MonitorMXBean, Serializable {
> private static final Logger log = LoggerFactory.getLogger(Monitor.class);
> private Boolean enabled = Boolean.FALSE;
> private Long valueOne;
> public Monitor() {
> log.debug("CTOR");
> }
> @Override
> public Boolean isEnabled() {
> return enabled;
> }
> @Override
> public void setEnabled(Boolean enabled) {
> this.enabled = enabled;
> }
> @Override
> public Long getValueOne() {
> return valueOne;
> }
> @Override
> public void setValueOne(Long valueOne) {
> this.valueOne = valueOne;
> }
> }
> </pre>
> And JMX MXBean
> <pre>
> import javax.management.MXBean;
> @MXBean
> public interface MonitorMXBean {
> void setEnabled(Boolean enabled);
> Boolean isEnabled();
> void setValueOne(Long valueOne);
> Long getValueOne();
> }
> </pre>
> 17:34:42,455 ERROR [org.jboss.as.weld] (MSC service thread 1-1) JBAS016001: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.stop(MBeanRegistrationService.java:132) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Is this related to: https://issues.jboss.org/browse/WFLY-822 ?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (AS7-4443) Admin console hangs with "Loading..." icon spinning
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/AS7-4443?page=com.atlassian.jira.plugin.s... ]
Heiko Braun commented on AS7-4443:
----------------------------------
Pleae open up another issue with the same description, but also provide some information about the actual server version.
> Admin console hangs with "Loading..." icon spinning
> ---------------------------------------------------
>
> Key: AS7-4443
> URL: https://issues.jboss.org/browse/AS7-4443
> Project: Application Server 7
> Issue Type: Bug
> Components: Console
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Pro 64-bit, Java Version 1.7.0_02, BJoss 7.1.1 Final installed from .zip
> Reporter: Dean Schulze
> Assignee: Heiko Braun
>
> localhost:8080 works. When I click on Admin Console the screen comes up with the "loading..." icon spinning on the screen, but hangs there. I have created an administrative user with add-user.bat but I don't get prompted for credentials. I have successfully installed a REST application with maven and it is working.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (AS7-4443) Admin console hangs with "Loading..." icon spinning
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/AS7-4443?page=com.atlassian.jira.plugin.s... ]
Heiko Braun edited comment on AS7-4443 at 12/5/14 11:06 AM:
------------------------------------------------------------
Please open up another issue with the same description, but also provide some information about the actual server version.
was (Author: heiko.braun):
Pleae open up another issue with the same description, but also provide some information about the actual server version.
> Admin console hangs with "Loading..." icon spinning
> ---------------------------------------------------
>
> Key: AS7-4443
> URL: https://issues.jboss.org/browse/AS7-4443
> Project: Application Server 7
> Issue Type: Bug
> Components: Console
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Pro 64-bit, Java Version 1.7.0_02, BJoss 7.1.1 Final installed from .zip
> Reporter: Dean Schulze
> Assignee: Heiko Braun
>
> localhost:8080 works. When I click on Admin Console the screen comes up with the "loading..." icon spinning on the screen, but hangs there. I have created an administrative user with add-user.bat but I don't get prompted for credentials. I have successfully installed a REST application with maven and it is working.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-449) MBeanRegistrationService throws NameNotFoundException "java:comp/BeanManager" when starting/stoping the MBean
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFCORE-449?page=com.atlassian.jira.plugin... ]
Amos Feng updated WFCORE-449:
-----------------------------
Labels: JMX (was: )
> MBeanRegistrationService throws NameNotFoundException "java:comp/BeanManager" when starting/stoping the MBean
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-449
> URL: https://issues.jboss.org/browse/WFCORE-449
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 1.0.0.Alpha13
> Reporter: Amos Feng
> Assignee: Amos Feng
> Labels: JMX
> Fix For: 1.0.0.Alpha14
>
>
> This issue happens if you create an MBean in your EJB and deploy the EJB. The steps to reproduce the issue is the following:
> {code}
> git clone https://github.com/zhfeng/test_jmx_ejb
> cd test_jmx_ejb
> mvn clean install
> {code}
> After starting the wildfly server, copy the test_jmx_ejb-1.0.jar to the deployment directory of the wildfly and you will see the exception
> {code}
> 11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {code}
> It looks like the JavaNamespaceSetup teardown happens before the WeldContextSetup so it throws NameNotFoundException in the WeldContextSetup teardown.
> The possible fix is to reverse calling the setupActions.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-449) MBeanRegistrationService throws NameNotFoundException "java:comp/BeanManager" when starting/stoping the MBean
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFCORE-449?page=com.atlassian.jira.plugin... ]
Amos Feng updated WFCORE-449:
-----------------------------
Description:
This issue happens if you create an MBean in your EJB and deploy the EJB. The steps to reproduce the issue is the following:
{code}
git clone https://github.com/zhfeng/test_jmx_ejb
cd test_jmx_ejb
mvn clean install
{code}
After starting the wildfly server, copy the test_jmx_ejb-1.0.jar to the deployment directory of the wildfly and you will see the exception
{code}
11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
{code}
It looks like the JavaNamespaceSetup teardown happens before the WeldContextSetup so it throws NameNotFoundException in the WeldContextSetup teardown.
The possible fix is to reverse calling the setupActions.
was:
The steps to reproduce the issue is the following:
{code}
git clone https://github.com/zhfeng/test_jmx_ejb
cd test_jmx_ejb
mvn clean install
after starting the wildfly server, copy the test_jmx_ejb-1.0.jar to the deployment directory of the wildfly
{code}
you will see the exception
{code}
11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
{code}
It looks like the JavaNamespaceSetup teardown happens before the WeldContextSetup so it throws NameNotFoundException in the WeldContextSetup teardown.
The possible fix is to reverse calling the setupActions.
> MBeanRegistrationService throws NameNotFoundException "java:comp/BeanManager" when starting/stoping the MBean
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-449
> URL: https://issues.jboss.org/browse/WFCORE-449
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 1.0.0.Alpha13
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 1.0.0.Alpha14
>
>
> This issue happens if you create an MBean in your EJB and deploy the EJB. The steps to reproduce the issue is the following:
> {code}
> git clone https://github.com/zhfeng/test_jmx_ejb
> cd test_jmx_ejb
> mvn clean install
> {code}
> After starting the wildfly server, copy the test_jmx_ejb-1.0.jar to the deployment directory of the wildfly and you will see the exception
> {code}
> 11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {code}
> It looks like the JavaNamespaceSetup teardown happens before the WeldContextSetup so it throws NameNotFoundException in the WeldContextSetup teardown.
> The possible fix is to reverse calling the setupActions.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months