5 Replies Latest reply on Sep 12, 2013 6:14 AM by Paul Robinson

    DemoATRecoveryModule.register() throws NPE on EAP6.1

    Tomohisa igarashi Master

      Hi folks,

       

      I'm now trying to deploy xts-demo on EAP 6.1 with using standalone-xts.xml copied from docs/examples/configs directory, but it fails with following errors:

      15:08:01,270 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/xts-demo-webservices]] (ServerService Thread Pool -- 70) JBWEB000287: Exception sending context initialized event to listener instance of class com.jboss.jbosstm.xts.demo.services.recovery.DemoATRecoveryListener: java.lang.NullPointerException

        at com.jboss.jbosstm.xts.demo.services.recovery.DemoATRecoveryModule.register(DemoATRecoveryModule.java:42) [xts-demo-core-4.17.4.Final.jar:]

        at com.jboss.jbosstm.xts.demo.services.recovery.DemoATRecoveryListener.contextInitialized(DemoATRecoveryListener.java:15) [xts-demo-core-4.17.4.Final.jar:]

        at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

        at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

        at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

        at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]

        at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]

        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

        at org.jboss.threads.JBossThread.run(JBossThread.java:122)

       

       

      15:08:01,290 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/xts-demo-webservices]] (ServerService Thread Pool -- 70) JBWEB000287: Exception sending context initialized event to listener instance of class com.jboss.jbosstm.xts.demo.services.recovery.DemoBARecoveryListener: java.lang.NullPointerException

        at com.jboss.jbosstm.xts.demo.services.recovery.DemoBARecoveryModule.register(DemoBARecoveryModule.java:43) [xts-demo-core-4.17.4.Final.jar:]

        at com.jboss.jbosstm.xts.demo.services.recovery.DemoBARecoveryListener.contextInitialized(DemoBARecoveryListener.java:15) [xts-demo-core-4.17.4.Final.jar:]

        at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]

        at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

        at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

        at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]

        at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]

        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

        at org.jboss.threads.JBossThread.run(JBossThread.java:122)

       

       

      15:08:01,304 INFO  [org.jboss.ws.cxf.deployment] (MSC service thread 1-1) JBWS024074: WSDL published to: file:/opt/JBossEAP/jboss-eap-6.1/xts/data/wsdl/ws-t11-coordinator.deployment/CompletionCoordinatorRPCService.wsdl

      15:08:01,305 INFO  [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-1) Creating Service {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationCoordinatorRPCPortTypeImplService from class com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorRPCPortTypeImpl

      15:08:01,314 INFO  [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-2) Setting the server's publish address to be http://localhost:8080/ws-t11-participant/BusinessAgreementWithCoordinatorCompletionParticipantService

      15:08:01,323 ERROR [org.apache.catalina.core] (ServerService Thread Pool -- 70) JBWEB001103: Error detected during context /xts-demo-webservices start, will stop it

       

      I checked out 4.17.4.Final tag from https://github.com/jbosstm/quickstart to build the xts-demo. Do I need to do something else to register this RecoveryModule?

       

      Thanks,

      Tomo

        • 1. Re: DemoATRecoveryModule.register() throws NPE on EAP6.1
          Paul Robinson Master

          Tomo,

           

          This can sometimes happen if you start the app server with an XTS application already installed. If this deployment is started before XTS, then the call to XTSBARecoveryManager.getRecoveryManager() returns null. Are you booting the AS withe the demo application in the deployment directory? This won't happen if you copy the application into the deploy directory after it boots, or if you modify the code to poll for the RecoveryManager until it's not null. Neither are particularly desirable, hence the Jira issue to fix this [1].

           

          However, from our discussion a while ago, I think you are more interested in distributing a JTA transaction via WS-AT. This is not covered in the XTS demo, which focusses on using the lower level APIs offered by XTS. I'd recommend you look at the TXBridge Demo [2] which covers this and is also a simpler place to start. This was the quickstart that Keith looked at, and I think it covers your requirements for SwitchYard.

           

          Paul.

           

          [1] [#JBTM-1917] XTS*RecoveryManager.getRecoveryManager() can return null if application deployed before XTS starts - JBoss …

          [2] https://github.com/jbosstm/quickstart/tree/4.17.9.Final/TXBridge/demo

          • 2. Re: DemoATRecoveryModule.register() throws NPE on EAP6.1
            Tomohisa igarashi Master

            Thank you for the prompt response, Paul! It works if I deploy it after eap boots.

             

            Initially I was trying TXBridge demo, but I also wanted to take a look at xts-demo since I noticed the outbound bridging of that demo depends on RestrantServiceAT in it.

             

            Now I'm wondering if I can use WS-AT framework and existing TXBridge, or I may need to implement another bridge for SwitchYard Tx propagation since SwitchYard remote invocation is using its own HTTP communication via plain servlet but not using SOAP WebService. So I'm now taking a look at TXBridge itself.

             

            Anyway, thanks again!

             

            Tomo

            • 3. Re: DemoATRecoveryModule.register() throws NPE on EAP6.1
              Paul Robinson Master

              Tomo,

               

              Initially I was trying TXBridge demo, but I also wanted to take a look at xts-demo since I noticed the outbound bridging of that demo depends on RestrantServiceAT in it.

              Ah yes, you are right, I had forgotten about that.

               

              Now I'm wondering if I can use WS-AT framework and existing TXBridge, or I may need to implement another bridge for SwitchYard Tx propagation since SwitchYard remote invocation is using its own HTTP communication via plain servlet but not using SOAP WebService. So I'm now taking a look at TXBridge itself.

              The code for starting a new WS-AT transaction and associating it with the existing JTA transaction can be found in org.jboss.jbossts.txbridge.outbound.JaxWSTxOutboundBridgeHandler. I think you should just be able to re-use that code. Once the WS-AT transaction has been begun, you will need to use the code in com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor to get the transaction context to put in your HTTP message. Currently that context is a piece of XML, which is not going to be too friendly in your scenario. Once you've proven the approach I can provide you with a mechanism for getting the transaction context in your preferred format. Roughly the opposite needs to be done on the server side, using org.jboss.jbossts.txbridge.inbound.JaxWSTxInboundBridgeHandler and com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor.

               

              Does that make sense?

               

              Paul.

              • 4. Re: DemoATRecoveryModule.register() throws NPE on EAP6.1
                Tomohisa igarashi Master

                Thanks for the advice! So the WS-AT should work even if actual service invocation is not a SOAP WebService? That sounds cool. Then I'll look for how/when to process those like JaxWSHeaderContextProcessor and inbound/outbound bridge processor in SwitchYard remote code.

                 

                Thanks,

                Tomo

                • 5. Re: DemoATRecoveryModule.register() throws NPE on EAP6.1
                  Paul Robinson Master

                  That's correct,

                   

                  The application message is orthogonal to the protocol messages that are exchanged. In-fact, it used to be the case that a different SOAP stack was used for protocol messages, to that used by the application. The key thing is that a transaction context is put in the message payload. The interceptors on either side deal with just that context. You could use a carrier pigeon to send the application message if you wanted [1], just make sure the transaction context is present ;-)

                   

                  Paul.

                   

                  [1] http://tools.ietf.org/html/rfc1149