[mauromol]

Thank you Andrew!

However I have some questions:

1) in this repo I find only beta versions; shouldn't I better use released versions? Please note I'm using JBossTS 4.11 Final and some JARs from JBossWS 3.3.1.GA...

2) do I need also jboss-logging-spi, jboss-logging-logmanager, jboss-logging-log4j/jboss-logging-jdk?

3) if I follow this path in Nexus:

JBoss Releases | org | jboss | logging

I find something similar. What's the difference between the two repositories?

4) I also find JARs of jboss-logging following the path that starts with "jboss" instead of "org": what's the difference?

Anyway, shouldn't these logging JARs be included in the lib folder of the binary releases of JBossTS and JBossWS, since they're needed?

Thank you in advance,

Mauro.

[adinn]

Mauro Molinari wrote:

Thank you Andrew!

However I have some questions:

1) in this repo I find only beta versions; shouldn't I better use released versions? Please note I'm using JBossTS 4.11 Final and some JARs from JBossWS 3.3.1.GA...

At present there are only beta versions. JBossTS 4.11 is a final release because we froze and tested it. This does not mean that it only consumes final releases of other projects. When AS 6 comes out (very soon) it will use 4.11 final and will probably also contain a final release fo JBoss logging but there is no guarantee even then. We only enforce that when we do a product release. We don't know of any problems with the Beta4 version of logging so it is probably no more risky to use it than any other community version. If you want some more certainty and more rigorous testing you will have to use the EAP 6 product release (and wait for the latest changes to get included) which wlll not happen for quite some time.

2) do I need also jboss-logging-spi, jboss-logging-logmanager, jboss-logging-log4j/jboss-logging-jdk?

I am not sure as JBoss AS sorts that out for me. You wil have to check the pom or try it and see.

3) if I follow this path in Nexus:

JBoss Releases | org | jboss | logging

I find something similar. What's the difference between the two repositories?

They are repo views which include stuff from several places. I think the JBoss Public releases includes more some legacy and some 3rd party but I am not sure. Either will do to find the code released by Jboss.

4) I also find JARs of jboss-logging following the path that starts with "jboss" instead of "org": what's the difference?

I think originally they were released just using 'jboss' as the groupid. However, maven deployers are trying to clear up repos so they use properly qualified group ids (e.g. you cannot now deploy to the central maven repo if you don't use an acceptable groupid). So, the ones with groupid 'jboss' are there for legacy so as nto to break existing builds.

Anyway, shouldn't these logging JARs be included in the lib folder of the binary releases of JBossTS and JBossWS, since they're needed?

No, We used to do this a long time ago but now the TS releases are built for inclusion in JBoss AS. It  implicitly provides most of the jars we depend on and we don't  care about how it does it. If we started supplying jars then this would risk  conflicts when JBoss AS changes its dependencies So, we only provide jars which are used during buidling or testing (e.g. we have jars for a forked version  emma to check our code coverage which includes patches not yet in an official release). I am afraid you will have to work out which extra jars you need to bundle with your app.

[mauromol]

Hi Andrew,

thanks again for your help. I've added the jboss-logging.jar. After that, the previous error did not happen anymore.

Next problem I solved was the setting of the coordinator URL (ActivationService): for my tests, it's ok to use the System properties, so that's ok.

Now I'm stuck at another point. When I try to invoke my client I get the following log entries/exceptions:

AVVERTENZA: Interceptor for {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now
java.lang.NullPointerException
 at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:831)
 at org.apache.cxf.ws.addressing.MAPAggregator.getActionFromInputMessage(MAPAggregator.java:597)
 at org.apache.cxf.ws.addressing.MAPAggregator.getActionUri(MAPAggregator.java:712)
 at org.apache.cxf.ws.addressing.MAPAggregator.validateIncomingMAPs(MAPAggregator.java:924)
 at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:496)
 at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:188)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
 at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
 at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
 at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
 at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
 at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:619)
1-set-2010 12.01.34 org.apache.cxf.ws.addressing.ContextUtils retrieveMAPs
AVVERTENZA: WS-Addressing - failed to retrieve Message Addressing Properties from context
1-set-2010 12.01.34 org.apache.cxf.ws.addressing.ContextUtils retrieveMAPs
AVVERTENZA: WS-Addressing - failed to retrieve Message Addressing Properties from context
1-set-2010 12.01.34 org.apache.cxf.ws.addressing.ContextUtils retrieveMAPs
AVVERTENZA: WS-Addressing - failed to retrieve Message Addressing Properties from context
1-set-2010 12.01.34 org.apache.cxf.ws.addressing.soap.MAPCodec restoreExchange
AVVERTENZA: Response message does not contain WS-Addressing properties.  Not correlating response.
1-set-2010 12.01.34 org.apache.cxf.ws.addressing.ContextUtils retrieveMAPs
AVVERTENZA: WS-Addressing - failed to retrieve Message Addressing Properties from context
com.arjuna.wst.SystemException: Receiver[javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing.][javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing.
 at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
 at $Proxy68.createCoordinationContextOperation(Unknown Source)
 at com.arjuna.webservices11.wscoor.client.ActivationCoordinatorClient.sendCreateCoordination(ActivationCoordinatorClient.java:85)
 at com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:76)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:270)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:85)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:75)
 at test.TestServiceClient.doGet(TestServiceClient.java:37)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.cxf.binding.soap.SoapFault: Fault occurred while processing.
 at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)
 at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)
 at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
 at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)
 at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
 at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
 at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:729)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2261)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2134)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1988)
 at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
 at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
 at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
 at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
 at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
 ... 21 more
]
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:285)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:85)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:75)
 at test.TestServiceClient.doGet(TestServiceClient.java:37)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:619)

What I understand is that the invocation of the ActivationService fails because there's a problem with the handling of the WS-Addressing headers. I think this problem is on the coordinator side, but I think I need some help to understand what's going on and what to do to fix this...

Thanks in advance,

Mauro.

[adinn]

Mauro Molinari wrote:

Next problem I solved was the setting of the coordinator URL (ActivationService): for my tests, it's ok to use the System properties, so that's ok.

You can always inject this URL into the WSCEnvironmentBean.

Now I'm stuck at another point. When I try to invoke my client I get the following log entries/exceptions:

AVVERTENZA: Interceptor for {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now
java.lang.NullPointerException
 at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:831)
 at org.apache.cxf.ws.addressing.MAPAggregator.getActionFromInputMessage(MAPAggregator.java:597)
 at org.apache.cxf.ws.addressing.MAPAggregator.getActionUri(MAPAggregator.java:712)
 at org.apache.cxf.ws.addressing.MAPAggregator.validateIncomingMAPs(MAPAggregator.java:924)
 at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:496)
 at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:188)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
 at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
 at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
 at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
 at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
 at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:619)

. . .

This first problem is happening in the server side when the CreateCoordinationContext request gets delivered. This is a problem I addressed some weeks ago. It is one of several problems which manifested in the XTS code when AS 6 moved onto CXF 2.2.9. The basic problem here is that the action and soap action are being specified differently. However, if I recall correctly there were quite a few other things I needed to fix. The subsequent errors also appear to be to do with issues related to this version upgrade. The relevant JIRAs for the fixes are here

https://jira.jboss.org/browse/JBTM-755

https://jira.jboss.org/browse/JBTM-753

https://jira.jboss.org/browse/JBTM-749

I thought these changes had gone into 4.11 but it looks like they only made it into 4.12. So, this means you will either have to patch your code by re-applying the changes made in these JIRAs  or else move to using 4.12. The first option is not easy as it requires making many small changes to lots of files. It owuld be much simpler to switch to using 4.12 and reapplying the fixes you have made to 4.11. However, in that case you might be better off using trunk since it already includes these changes and other things you want.(n.b. I have just finished testing and am about to commit to trunk the  change to allow you to drop the service endpoints in the client side). We will be freezing trunk to produce release 4.13 in about 5 weeks so it will nto be troo long before you can be working off a tagged release.


There is a another version issue here you need to be aware of. Some of these problems caused when we moved up to 2.2.9 were because of a regression in CXF itself which required a patch:

https://issues.apache.org/jira/browse/CXF-2860

Our latest JBoss AS release is based on a special build of 2.2.9 because we could not wait for a CXF relase to fix this. However, Jim Ma has included the fix in cxf 2.2.10 and cxf 2.3. So, you will need to be using one of these later versions in order to get this patch. Without it XTS error handling and recovery will not work properly.

[mauromol]

Hi Andrew, I'm working in my spare time on this now, so I'm slower.

Anyway, I'm using CXF 2.2.10, so I must be affected by the bugs you mentioned. By the way, is there a reason for which JBossTS 4.12 appears as released on 2 August 2010 in JIRA while not being available on JBossTS site download page?

I may come back to go forth once 4.12 (or, even better, 4.13) is made available for downloading.

Thanks again,

Mauro.

[adinn]

Hi Mauro,

Apologies for not replying earlier -- the forum must be playing up as I did not get a notification of your reply.

Mauro Molinari wrote:

Anyway, I'm using CXF 2.2.10, so I must be affected by the bugs you mentioned. By the way, is there a reason for which JBossTS 4.12 appears as released on 2 August 2010 in JIRA while not being available on JBossTS site download page?

I may come back to go forth once 4.12 (or, even better, 4.13) is made available for downloading.

CXF 2.2.10 is fine -- it contains the fixes made on behalf of XTS. The problem is that you also need the XTS fixes which are only in 4.12 or trunk (i.e. what will be 4.13). Waiting for 4.13 will be best as it includes all the extra features you wanted. Release is scheduled for 15th October but we might possibly bring it forward to  8th October depending upon how things go.

4.12 is currently only available as a source download from the svn repo

  http://anonsvn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_12_0_Final/

The TS team does not always push out binary releases for every tag. They are often pulled into the repo by the AS team when they are needed for a specific AS release. So far, 4.12 has been used in the 6.0.0.M3/4 AS releases which are incomplete versions. When AS 6.0.0.Final is released (it's being prepared for release right now) a 4.12 binary release should be pulled into the maven repo.

[mauromol]

Hi Andrew!

I'm back here after the availability of JBossTS 4.13.1 in the JBossTS download page.

I picked back up my three projects (Client, Participant, Coordinator) and did the following on them:

- upgraded JBossTS JTA and XTS from 4.11.0 to 4.13.1

- thrown away all the previous configuration efforts and switched to the new mechanism

First of all, I would like to say that you've done an excellent job on the configuration system. In particular I appreciate very much not only the result, but also how you commented this result: the xts-properties11.xml has a lot of comments that explain very clearly what you should enable/disable. Moreover, with the new version I could set up the three deployed components (Client, Participant, Coordinator) without touching any XTS source files, just providing the JARs and supplying the needed configuration.

Now, this is my current questions/problems/suggested improvements:

1.  now the WSDLs are directly inside the XTS JARs: great, since I just checked that CXF lets you expose those WSDLs even if they're inside a JAR (through an URL in the form of "classpath:/my/path/mywsdl.wsdl" or even "jar:file:myjar.jar!/my/path/mywsdl.wsdl"); this means that to deploy outside JBoss AS I have all the things I need by simply deploy the XTS JARs in WEB-INF/lib. Just an exception: the service classes (XTSService, XTSServiceMBean, the initialitation classes) are only present in the sar. What I had to do was to rename that sar to jar and remove all of its contents except for the classes and the manifest. If these classes were present in one of the other JARs (or in a separate JAR) I could have forgotten the sar, which I actually shouldn't need for my deploy on Tomcat.

2. now the documentation is very clear about what you can include or omit in the configuration depending of your deploy needs (Client, Participant or Coordinator components). However, there's no guide about the needed JARs. By now I deployed all the XTS JARs on all of my test webapps, but I think that a subset of them could be enough for each of the different parts.

3. the WSDLs of the WS-C services (wsat-coordinator-binding and wscoor-activation-binding) are located in two places, in ws-c11.jar but also in wstx.jar; by now I'm using the ones in ws-c11.jar, because they appear to be the WS-C counterparts of the WS-T services in ws-t11.jar, but I don't know if there is any reason for them to be in wstx.jar too.

4. I have a doubt on the configuration of the Coordinator URL when I'm deploying just the Coordinator component. Should I specify a URL to itself or rather leave it unspecified? If the answer is the latter one, does it mean that the Coordinator service is not needed by the Coordinator component itself or that it defaults to searching for it at localhost?

5. it's not clear to me if any work has been done regarding the configuration of the different service URLs; I mean, is it now possible to configure XTS so that it searches for the different WS-T/WS-C services at specific URLs/paths or are they still hardcoded to the JBossAS default endpoint paths?

6. once I start the Coordinator component (xts-properties.xml configured and supplied to the EnvironmentBeans, then XTSService.start() called), I get a NullPointerException by the Periodic Recovery Thread, with the following stack trace:

Exception in thread "Periodic Recovery" java.lang.NullPointerException
 at org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule.processTransactionsStatus(ATCoordinatorRecoveryModule.java:280)
 at org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule.periodicWorkSecondPass(ATCoordinatorRecoveryModule.java:121)
 at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
 at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)

By debugging I see that XTSATRecoveryManager.getRecoveryManager() returns null. In xts-properties.xml I have configured just the following recovery modules, which should be the only needed ones:

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>

Any idea on what's wrong?

Thanks in advance, as usual...

Mauro.

[adinn]

Hi Mauro,

I am glad to see you picked up the 4.13 release and gave it a try. I was intending to post you a resposne to say it was ready but you got there first.

Mauro Molinari wrote:

First of all, I would like to say that you've done an excellent job on the configuration system. In particular I appreciate very much not only the result, but also how you commented this result: the xts-properties11.xml has a lot of comments that explain very clearly what you should enable/disable. Moreover, with the new version I could set up the three deployed components (Client, Participant, Coordinator) without touching any XTS source files, just providing the JARs and supplying the needed configuration.

Thanks very much for the feedback, especially for providing such a detailed and precise list of the remaining issues. Thsi is a big help in getting the quality of the product up to the level we really want.

Mauro Molinari wrote:

1.  now the WSDLs are directly inside the XTS JARs: great, since I just checked that CXF lets you expose those WSDLs even if they're inside a JAR (through an URL in the form of "classpath:/my/path/mywsdl.wsdl" or even "jar:file:myjar.jar!/my/path/mywsdl.wsdl"); this means that to deploy outside JBoss AS I have all the things I need by simply deploy the XTS JARs in WEB-INF/lib. Just an exception: the service classes (XTSService, XTSServiceMBean, the initialitation classes) are only present in the sar. What I had to do was to rename that sar to jar and remove all of its contents except for the classes and the manifest. If these classes were present in one of the other JARs (or in a separate JAR) I could have forgotten the sar, which I actually shouldn't need for my deploy on Tomcat.

There is no reason why the classes in the .sar cannto be embedded in another jar. Please raisea JIRA for this and I will fix it in the next release.

Mauro Molinari wrote:

2. now the documentation is very clear about what you can include or omit in the configuration depending of your deploy needs (Client, Participant or Coordinator components). However, there's no guide about the needed JARs. By now I deployed all the XTS JARs on all of my test webapps, but I think that a subset of them could be enough for each of the different parts.

The jars have not been separated into client, participant and coordinator components because the dependencies between the classes are quite complex. This division cuts across the organizaton of the source code which is by function (WSAS, WSCF, WS-C, WS-T, WSTX), subdivided by protocol version  (generic, 1.0, 1.1). It might be possible to factor the classes further into groups which are  needed to support either Client, Participant or Coordinator and, indeed, I woudl prefer t be in a situation where this was how it was organized. Unfortunately, the code grew into this shape via lot sof intermediate version which di very different things and changing it now woudl be very difficult to achieve.

There would be 7 factorizations required if you include code needed for only one, only two or all three depoyments. Multiplying by the existing sourec organization hat makes 5 * 3 * 7 different factored sets in all -- not exactly a straightforward structure to impose  or, more importantly, maintain even if we were to start from scratch, never mind retro-fitting this to existing code not designed around such a structure.

More importanlty, there is not a lot of harm in deploying all the code to all servers. Disk is cheap, zip file indexes are fairly small and quick to scan and the code only gets loaded from disk if it is needed. So, I am not rating this as a priority. But please raise a JIRA if you want. You are also welcome to fix it and send in the patches too :-)

Mauro Molinari wrote:

3. the WSDLs of the WS-C services (wsat-coordinator-binding and wscoor-activation-binding) are located in two places, in ws-c11.jar but also in wstx.jar; by now I'm using the ones in ws-c11.jar, because they appear to be the WS-C counterparts of the WS-T services in ws-t11.jar, but I don't know if there is any reason for them to be in wstx.jar too.

They were in the ws-c11 jar so the coordinator service classes (also in this jar) can find them. They were in wstx11.jar so the client classes (also in wstx11.jar) can find them. You are right that there is no need for this repetition so long as all the jars are deployed.

Mauro Molinari wrote:

4. I have a doubt on the configuration of the Coordinator URL when I'm deploying just the Coordinator component. Should I specify a URL to itself or rather leave it unspecified? If the answer is the latter one, does it mean that the Coordinator service is not needed by the Coordinator component itself or that it defaults to searching for it at localhost?

The coordinator URL configuration is only used by the client underneath calls to UserTransaction.begin or UserBusinessActivity.begin to tak to the ActivationCoordinator service. Only the client talks to this particular service. All subsequent communications use URLS which are determined either by this choice of (activation) coordinator URL or by the location of the web service or client.

So, enlistment requests from web service partiicpants to coordinator use the URL of the registration service (the coordinator writes this into the context returned under the begin call). The registration service hands back to the web service participant a URL for the protocol-specific coordination service and satshes away the URL of the corresponding participant service which is handed over in the enlist request.

Similarly, when the client enlists with the registration service for the AT or BA completion/termination coordinator protocol (that's the servcie it uses to request that the transaction is rolled forward or rolled back) it sends the enlist request to the registration service using the URL in the context. It  gets posted back the URL of the protocol-specific completion/termination service. When the client sends a termination request to this service under commit or rollback (or under close or cancel for BA) it supplies the URL of the client's completion/termination participant service.

So, in summary, the coordinator and web servcie host don't actually care what the coordinatorURL config setting is since they never use it.

Mauro Molinari wrote:

5. it's not clear to me if any work has been done regarding the configuration of the different service URLs; I mean, is it now possible to configure XTS so that it searches for the different WS-T/WS-C services at specific URLs/paths or are they still hardcoded to the JBossAS default endpoint paths?

No, this has not been made configurable since in the JBoss deployment it *must* match the scheme followed by the JBossWS code for locating endpoints defined in the web.xml. So, for example, the activation service URL has to be http://bindAddress:bindPort/ws-c11/ActivationService because the war file name ws-c11 is included as a prefix to the ActivationService path specified in the web.xml.

That is not to say that the URL path component cannot be made configurable, either via the beans file or the property config e.g. you could provide either a full path or a path prefix and service name suffix. Raise a JIRA if you want this and we can discuss the details there.

Mauro Molinari wrote:

6. once I start the Coordinator component (xts-properties.xml configured and supplied to the EnvironmentBeans, then XTSService.start() called), I get a NullPointerException by the Periodic Recovery Thread, with the following stack trace:

Exception in thread "Periodic Recovery" java.lang.NullPointerException
 at org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule.processTransactionsStatus(ATCoordinatorRecoveryModule.java:280)
 at org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule.periodicWorkSecondPass(ATCoordinatorRecoveryModule.java:121)
 at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
 at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)

By debugging I see that XTSATRecoveryManager.getRecoveryManager() returns null. In xts-properties.xml I have configured just the following recovery modules, which should be the only needed ones:

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>

Any idea on what's wrong?

Hmm, that's a bug. The recovery manager is being initialised by the ATParticipantRecoveryModule. However,it is needed by both the participant and the coordinator recovery modules. Raise a JIRA for this and I will try to fix it for the next release.

You should be able to work around this by also registering the participant recovery module as a coordinator recovery module (the class you need is org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule). That will load a bit of code you don't need and add a recovery check which will never find any work to do but it should not do any harm.

Ok, I'm looking forward to seeing all those JIRAs ;-)

regards,

Andrew Dinn

[mauromol]

Andrew Dinn ha scritto:

There is no reason why the classes in the .sar cannto be embedded in another jar. Please raisea JIRA for this and I will fix it in the next release.

Here it is: https://jira.jboss.org/browse/JBTM-798

Andrew Dinn ha scritto:

The jars have not been separated into client, participant and coordinator components because the dependencies between the classes are quite complex. This division cuts across the organizaton of the source code which is by function (WSAS, WSCF, WS-C, WS-T, WSTX), subdivided by protocol version  (generic, 1.0, 1.1). It might be possible to factor the classes further into groups which are  needed to support either Client, Participant or Coordinator and, indeed, I woudl prefer t be in a situation where this was how it was organized. Unfortunately, the code grew into this shape via lot sof intermediate version which di very different things and changing it now woudl be very difficult to achieve.

There would be 7 factorizations required if you include code needed for only one, only two or all three depoyments. Multiplying by the existing sourec organization hat makes 5 * 3 * 7 different factored sets in all -- not exactly a straightforward structure to impose  or, more importantly, maintain even if we were to start from scratch, never mind retro-fitting this to existing code not designed around such a structure.

More importanlty, there is not a lot of harm in deploying all the code to all servers. Disk is cheap, zip file indexes are fairly small and quick to scan and the code only gets loaded from disk if it is needed. So, I am not rating this as a priority. But please raise a JIRA if you want. You are also welcome to fix it and send in the patches too :-)

I understand the issue. Since this is not so much important, I wouldn't even bother to open a JIRA for this. After all, about 850KB of JARs on each side is not that much :-)

Andrew Dinn ha scritto:

They were in the ws-c11 jar so the coordinator service classes (also in this jar) can find them. They were in wstx11.jar so the client classes (also in wstx11.jar) can find them. You are right that there is no need for this repetition so long as all the jars are deployed.

Should I open a JIRA for this or do you prefer to keep the current situation? Since you previously said the the JARs have to be deployed altogether, I think that the client classes should be able to find the WSDLs even if they are just in ws-c11.jar, shouldn't them?

Andrew Dinn ha scritto:

The coordinator URL configuration is only used by the client underneath calls to UserTransaction.begin or UserBusinessActivity.begin to tak to the ActivationCoordinator service. Only the client talks to this particular service. All subsequent communications use URLS which are determined either by this choice of (activation) coordinator URL or by the location of the web service or client.

Shame on me, I should have read the comments to the CoordinatorURL part of the configuration file better: the first line clearly states "the following entries are used in the client container only..."!!

Andrew Dinn ha scritto:

No, this has not been made configurable since in the JBoss deployment it *must* match the scheme followed by the JBossWS code for locating endpoints defined in the web.xml. So, for example, the activation service URL has to be http://bindAddress:bindPort/ws-c11/ActivationService because the war file name ws-c11 is included as a prefix to the ActivationService path specified in the web.xml.

That is not to say that the URL path component cannot be made configurable, either via the beans file or the property config e.g. you could provide either a full path or a path prefix and service name suffix. Raise a JIRA if you want this and we can discuss the details there.

Here it is: https://jira.jboss.org/browse/JBTM-799

Andrew Dinn ha scritto:

Hmm, that's a bug. The recovery manager is being initialised by the ATParticipantRecoveryModule. However,it is needed by both the participant and the coordinator recovery modules. Raise a JIRA for this and I will try to fix it for the next release.

And here is the last one: https://jira.jboss.org/browse/JBTM-800

Thank you Andrew! :-)

Mauro.

[mauromol]

Andrew Dinn ha scritto:

You should be able to work around this by also registering the participant recovery module as a coordinator recovery module (the class you need is org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule). That will load a bit of code you don't need and add a recovery check which will never find any work to do but it should not do any harm.

Hmmm... I'm still getting the NPE. Now in xts-properties.xml I have:

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.participantRecoveryModule1">org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule</entry>

However I still get the same exception (with the same stack trace). Even if I specify the Participant Recovery Module before the Coordinator ones it doesn't work. Any idea?

Mauro.

[adinn]

Mauro Molinari wrote:

Hmmm... I'm still getting the NPE. Now in xts-properties.xml I have:

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.participantRecoveryModule1">org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule</entry>

However I still get the same exception (with the same stack trace). Even if I specify the Participant Recovery Module before the Coordinator ones it doesn't work. Any idea?

The recovery modules get run in the order they are enlisted so, yes, the participant module should come first in order to ensure that the manager is assigned before running the coordinator modules

[adinn]

Mauro Molinari wrote:

Andrew Dinn ha scritto:

They were in the ws-c11 jar so the coordinator service classes (also in this jar) can find them. They were in wstx11.jar so the client classes (also in wstx11.jar) can find them. You are right that there is no need for this repetition so long as all the jars are deployed.

Should I open a JIRA for this or do you prefer to keep the current situation? Since you previously said the the JARs have to be deployed altogether, I think that the client classes should be able to find the WSDLs even if they are just in ws-c11.jar, shouldn't them?

Yes, I'll have a JIRA please.

[mauromol]

Andrew Dinn ha scritto:

Mauro Molinari wrote:

Hmmm... I'm still getting the NPE. Now in xts-properties.xml I have:

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.participantRecoveryModule1">org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule</entry>

However I still get the same exception (with the same stack trace). Even if I specify the Participant Recovery Module before the Coordinator ones it doesn't work. Any idea?

The recovery modules get run in the order they are enlisted so, yes, the participant module should come first in order to ensure that the manager is assigned before running the coordinator modules

Hi Andrew,

this is not enough, indeed. To make the ParticipantRecoveryInitialisation to execute (which is the one that sets that recovery manager instance) I have to also uncomment the ParticipantSideInitialisation in xts-properties.xml.

Anyway, I have a doubt on the synchronization: the whole thing seems to work even if I uncomment the ParticipantSideInitialisation but I leave the definition of ATParticipantRecoveryModule AFTER that of the Coordinator recovery modules (like it is in the template xts-properties11.xml found in xts/config folder of the source distribution).

I think this is because the whole initialisation takes place in one thread, while the periodic recovery happens in another. So, the only requirement is that the initialisation has finished BEFORE the periodic recovery thread starts to use the recovery manager. However, my concern is that since this code is not synchronized, in some circumstances the periodic recovery thread may fail even if I move the definition of ATParticipantRecoveryModule before those of the Coordinator recovery modules.

I don't know if I've been sufficiently clear... Maybe I'm totally wrong.

Mauro.

[mauromol]

Andrew Dinn ha scritto:

Mauro Molinari wrote:

Andrew Dinn ha scritto:

They were in the ws-c11 jar so the coordinator service classes (also in this jar) can find them. They were in wstx11.jar so the client classes (also in wstx11.jar) can find them. You are right that there is no need for this repetition so long as all the jars are deployed.

Should I open a JIRA for this or do you prefer to keep the current situation? Since you previously said the the JARs have to be deployed altogether, I think that the client classes should be able to find the WSDLs even if they are just in ws-c11.jar, shouldn't them?

Yes, I'll have a JIRA please.

Here it is: https://jira.jboss.org/browse/JBTM-803

Thank you!

Mauro.

[mauromol]

Anyway, I think I'm at a good point now: the error I get when I try to launch a servlet which acts as a client to a webservice (and uses transaction demarcation through XTS) is the following:

AVVERTENZA: Interceptor for {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
 at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
 at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
 at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
 at $Proxy71.createCoordinationContextOperation(Unknown Source)
 at com.arjuna.webservices11.wscoor.client.ActivationCoordinatorClient.sendCreateCoordination(ActivationCoordinatorClient.java:85)
 at com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:77)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:289)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:80)
 at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:70)
 at test.TestServiceClient.doGet(TestServiceClient.java:37)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: IOException invoking http://ws-mauro.ost.lan:8080/ws-c11/ActivationService: HTTP response '404: Not Found'
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:2058)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2043)
 at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
 at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:639)
 at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
 ... 27 more
Caused by: java.io.IOException: HTTP response '404: Not Found'
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2194)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2134)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1988)
 ... 30 more

which means I need to configure the WSDL endpoint URL of the ActivationService. Unfortunately, I can't go futher with my experiments until this is doable.

Thanks for your support!

Mauro.