AbstractOperationContext.java line 1159 seems to be "swallowing" exceptions. It's possible to get NullPointerException without a stack trace. This makes it impossible to trace the cause of the NPE. https://github.com/jbossas/jboss-eap/blob/2292b0a8763683d0fab03efc3de6a29b974c09eb/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L1159 2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-11) Finding class org.jboss.logging.DelegatingBasicLogger from Module "org.picketbox:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base)) 2015-02-27 12:53:26,586 ERROR [|] [org.jboss.as.controller.client] (ServerService Thread Pool -- 29) JBAS014781: Step handler org.jboss.as.controller.AbstractAddStepHandler$1@1e6a7c88 for operation {"operation" => "add","factory-class" => "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory","param" => [("host" => "tp4.app.paypoint.net"),("port" => "6495"),("use-nio" => "true")],"address" => [("subsystem" => "messaging"),("hornetq-server" => "default"),("connector" => "tp4")],"socket-binding" => undefined} at address [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("connector" => "tp4") ] failed handling operation rollback -- java.lang.NullPointerException 2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-4) Finding class org.jboss.remoting3.UnlockedReadHashMap$EntryIterator from Module "org.jboss.remoting3:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
Created upstream issue: https://issues.jboss.org/browse/WFCORE-587
Reporting message was left as it was - it's supposed to go to a client and Brian doesn't want it to contain stack traces. Instead, the message is additionally logged in server log, this time with a stack trace.
PR: https://github.com/jbossas/jboss-eap/pull/2352
Fixed PR: https://github.com/jbossas/jboss-eap/pull/2400 Noticed there was an extra commit in the original one.
I'm sorry for not having automated test for this issue. I consulted with Martin Simka, and we concluded that byteman rule could be an appropriate way of reproducing this. So, the recipe for reproducer is following: 1) Start EAP. 2) Install byteman: bminstall.sh -b -Dorg.jboss.byteman.transform.all {EAP_process_ID} 2) Load following byteman rule: RULE break result handler CLASS org.jboss.as.controller.OperationContext$ResultHandler$1 METHOD handleResult AT EXIT IF true DO traceln("breaking at " + java.util.Arrays.toString(Thread.currentThread().getStackTrace())); throw new java.lang.RuntimeException("test exception") ENDRULE with command: bmsubmit.sh -l file_with_byteman_rule.btm 3) Within couple of seconds, following error message should be printed in standard output as well as in server.log, together with its' stack trace. 10:20:57,347 ERROR [org.jboss.as.controller.management-operation] (DeploymentSca nner-threads - 1) JBAS014781: Step handler org.jboss.as.controller.ModelControll erImpl$DefaultPrepareStepHandler@796dcbb9 for operation {"operation" => "read-ch ildren-resources","address" => [],"child-type" => "deployment","include-runtime" => undefined,"recursive" => undefined,"recursive-depth" => undefined,"proxies" => undefined,"include-defaults" => undefined} at address [] failed handling oper ation rollback -- java.lang.RuntimeException: test exception: java.lang.RuntimeE xception: test exception ... The message should be repeated every couple of seconds, since it's triggered by deployment scanner in this case. When using the EAP version before the fix, no error message appears at all.
Verified in EAP 6.4.3.CR1.
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.