[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1127593|https://bugzilla.redhat.com/show_bug.cgi?id=1127593] from POST to ASSIGNED
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3778:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1105003
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Beta1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3799?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3799:
------------------------------
Component/s: Build System
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-3799
> URL: https://issues.jboss.org/browse/WFLY-3799
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System, Server
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
>
> I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core:
> {code}
> INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3774) CDI bean with StereoType is not injectable in implicit bean archive
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/WFLY-3774?page=com.atlassian.jira.plugin.... ]
Takayoshi Kimura commented on WFLY-3774:
----------------------------------------
Ok, thanks for clarifying that. I thought the "scope annotations" part also applies to stereotype with default scope.
> CDI bean with StereoType is not injectable in implicit bean archive
> -------------------------------------------------------------------
>
> Key: WFLY-3774
> URL: https://issues.jboss.org/browse/WFLY-3774
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Reporter: Takayoshi Kimura
> Assignee: Jozef Hartinger
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
> Attachments: logs.zip, stereotype.zip
>
>
> CDI 1.2 defines bean defining annotations and with beans with these annotations should be injectable. However a bean with StereoType, one of bean defining annotations, is not injectable within implicit bean archive on WildFly.
> Attached a simple war project to reproduce this problem. This works on GlassFish 4 but doesn't work on WildFly 8.1.0 nor WildFly 9 master at this time. Making this an explicit bean archive by adding empty beans.xml (or set bean-discovery-mode=all) fixes the problem, the container recognizes the CDI bean correctly.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1127593|https://bugzilla.redhat.com/show_bug.cgi?id=1127593] from NEW to POST
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-1172:
---------------------------------------
With latest master including this patch times are normal again.
You also can see this on wildfly-ci. Times are down to ~ 1h again, from ~ 1h 18m.
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Fix For: 9.0.0.Beta1
>
> Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1119:
------------------------------
Assignee: Tom Jenkinson (was: Jeff Mesnil)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Tom Jenkinson
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3774) CDI bean with StereoType is not injectable in implicit bean archive
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3774?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger updated WFLY-3774:
----------------------------------
Fix Version/s: 8.2.0.CR1
{quote}Sorry I wasn't clear on that point. CDI 1.2 clearly listed what is injectable, but it also applies to CDI 1.1. This behavior is nothing changed between versions, it just got clearer definistion.{quote}
You are wrong. @Stereotypes being recognized as bean defining annotations is a new feature of CDI 1.2 - see e.g. http://www.cdi-spec.org/news/2014/04/14/CDI-1_2-released/
More precisely, in CDI 1.1, only scope annotations are considered bean defining annotations:
http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations
In CDI 1.2 this was extended to cover @Stereotypes and some other annotations:
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations
> CDI bean with StereoType is not injectable in implicit bean archive
> -------------------------------------------------------------------
>
> Key: WFLY-3774
> URL: https://issues.jboss.org/browse/WFLY-3774
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Reporter: Takayoshi Kimura
> Assignee: Jozef Hartinger
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
> Attachments: logs.zip, stereotype.zip
>
>
> CDI 1.2 defines bean defining annotations and with beans with these annotations should be injectable. However a bean with StereoType, one of bean defining annotations, is not injectable within implicit bean archive on WildFly.
> Attached a simple war project to reproduce this problem. This works on GlassFish 4 but doesn't work on WildFly 8.1.0 nor WildFly 9 master at this time. Making this an explicit bean archive by adding empty beans.xml (or set bean-discovery-mode=all) fixes the problem, the container recognizes the CDI bean correctly.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1119:
------------------------------
Component/s: Transactions
(was: JMS)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Jeff Mesnil
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFCORE-29:
-----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1120535|https://bugzilla.redhat.com/show_bug.cgi?id=1120535] from ON_QA to VERIFIED
> 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.3.1#6329)
9 years, 8 months