XTS 4.7.0 over JBoss Metro Stack

[gllambi]

Hi!! Is it possible to use the XTS with JBossWS Metro Stack?

Thanks in advance!
Guzman

[gllambi]

"gllambi" wrote:
Hi!! Is it possible to use the XTS with JBossWS Metro Stack?

Thanks in advance!
Guzman

Forgot something.... and with the txBridge?

[jhalliday]

Nope, JBossWS Native only for now. Perhaps CXF soon. No plans for Metro.

[gllambi]

"jhalliday" wrote:
Nope, JBossWS Native only for now. Perhaps CXF soon. No plans for Metro.

Thank you very much halliday!

So, if I want to use the XTS & txBridge with the Metro Stack, the only chance is to use it as stand alone or this can't be possible also?

[adinn]

So, if I want to use the XTS & txBridge with the Metro Stack, the only chance is to use it as stand alone or this can't be possible also?

No, you will not be able to use it standalone either. The problem is that Sun dropped the API for manipulating AddressingProperties from the JaxWS standard (I think the idea was to make JAXWS-WSA as simple as possible but they ended up making it simpler than that). Without (some version of) this API it is not possible to use the WS-Addressing capablility implemented in Metro to provide the headers required on WS-AT and WS-BA messages -- at least not in a portable way. JBossWS-Native and CXF both provide implementations of the dropped API so we have been able to implement XTS over these stacks.

The only way to get XTS to work on Metro would be to implement (and, more importantly, maintain) this API in Metro. I did prototype an implementation by stealing some of the JBossWS code and got an old version of XTS to run inside Glassfish. However, the code is most definitely not production quality and I am not planning to do more work on it.

[gllambi]

"adinn" wrote:

No, you will not be able to use it standalone either. The problem is that Sun dropped the API for manipulating AddressingProperties from the JaxWS standard (I think the idea was to make JAXWS-WSA as simple as possible but they ended up making it simpler than that). Without (some version of) this API it is not possible to use the WS-Addressing capablility implemented in Metro to provide the headers required on WS-AT and WS-BA messages -- at least not in a portable way. JBossWS-Native and CXF both provide implementations of the dropped API so we have been able to implement XTS over these stacks.

The only way to get XTS to work on Metro would be to implement (and, more importantly, maintain) this API in Metro. I did prototype an implementation by stealing some of the JBossWS code and got an old version of XTS to run inside Glassfish. However, the code is most definitely not production quality and I am not planning to do more work on it.

Adinn, thank you very much for the quick answer!

To understand it correctly, the main problem with this scenario (stand alone coordinator + transactional WS over Metro Stack on JBoss Server) is the implementation of the participants, isn't it? I assume that the coordinator can run on other JBoss AS with Native Stack, so no extra implementation is needed for it.

Thanks again!
Guzman

[adinn]

To understand it correctly, the main problem with this scenario (stand alone coordinator + transactional WS over Metro Stack on JBoss Server) is the implementation of the participants, isn't it? I assume that the coordinator can run on other JBoss AS with Native Stack, so no extra implementation is needed for it.

Actually, there is also the client to consider as well as the transactional web service (participants and the coordinator. However, it does not really matter which of these 3 components you want to run over JBoss/Metro. Limiting the use case to the web service does not simplify the problem. All 3 agents in the transaction (client, coordinator and participant) use JaxWS/SOAP to send/receive messages. All 3 of them need to be able to ensure that the correct WSA headers are attached to these SOAP messages. They all employ the behaviour which was originally specified in the JaxWS standard for class javax.xml.ws.addressing.AddressingProperties and its related classes. They all require the SOAP stack to respond correctly to the presence of an instance of this class on the SOAP message context. So fixing one of them is the same as fixing all of them.

[gllambi]

"adinn" wrote:

To understand it correctly, the main problem with this scenario (stand alone coordinator + transactional WS over Metro Stack on JBoss Server) is the implementation of the participants, isn't it? I assume that the coordinator can run on other JBoss AS with Native Stack, so no extra implementation is needed for it.

Actually, there is also the client to consider as well as the transactional web service (participants and the coordinator. However, it does not really matter which of these 3 components you want to run over JBoss/Metro. Limiting the use case to the web service does not simplify the problem. All 3 agents in the transaction (client, coordinator and participant) use JaxWS/SOAP to send/receive messages. All 3 of them need to be able to ensure that the correct WSA headers are attached to these SOAP messages. They all employ the behaviour which was originally specified in the JaxWS standard for class javax.xml.ws.addressing.AddressingProperties and its related classes. They all require the SOAP stack to respond correctly to the presence of an instance of this class on the SOAP message context. So fixing one of them is the same as fixing all of them.

ah.... ok! I undertand it better now. Thanks again for the detailed explanation and patience

Regards
Guzman

[luigib]

Sorry for using the same topic, but I believe my question is related to this one.

From the documentation and the jira (https://jira.jboss.org/jira/browse/JBTM-265 and https://jira.jboss.org/jira/browse/JBTM-621), I understand that a build of XTS capable of working with the JBoss CXF stack is almost complete. Will this target only JBoss 6 (as XTS 4.8 does) or is there in your plans a JBoss 5.x compatible version (I suppose this would use XTS 4.7.x)?

Thank you very much

Regards
Luigi

[jhalliday]

We are not currently testing new JBossTS feature releases against AS 5.x They may work with a greater or lesser amount of tweaking, but our target environment is now AS 6. The one caveat to that is: EAP customers MAY get XTS on JBossWS-CXF support in EAP 5.1 if they ask for it enough.

[luigib]

Thanks for your reply.
I have actually deployed XTS 4.7 to JBoss AS 5.1/CXF 3.2.1 and everything seems actually ok until I try to run the demo. At that point I get the following exception that seems to be (I might be wrong) related to https://jira.jboss.org/jira/browse/JBTM-621 (dual source map layer, fixed in XTS 4.8):


java.lang.NoClassDefFoundError: javax/xml/ws/addressing/AddressingBuilder
org.jboss.jbossts.xts.wsaddr.map.MAPBuilder.(MAPBuilder.java:72)
org.jboss.jbossts.xts.wsaddr.map.MAPBuilder.(MAPBuilder.java:78)
com.arjuna.webservices11.wsaddr.AddressingHelper.createRequestContext(AddressingHelper.java:132)
com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:62)
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:277)
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:85)
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:75)
com.jboss.jbosstm.xts.demo.client.BasicClient.testAtomicTransaction(BasicClient.java:456)
com.jboss.jbosstm.xts.demo.client.BasicClient.doGet(BasicClient.java:408)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)


In your opinion it would take a lot of tweaking to backport your modifications to XTS 4.7.x and JBoss 5.1? I am inclined to think that it wouldn't, but your informed opinion would be most appreciated (and useful) before I venture in investigating the issue further.

Thanks again

Regards
Luigi

[adinn]

I have actually deployed XTS 4.7 to JBoss AS 5.1/CXF 3.2.1 and everything seems actually ok until I try to run the demo. At that point I get the following exception that seems to be (I might be wrong) related to https://jira.jboss.org/jira/browse/JBTM-621 (dual source map layer, fixed in XTS 4.8):

java.lang.NoClassDefFoundError: javax/xml/ws/addressing/AddressingBuilder
org.jboss.jbossts.xts.wsaddr.map.MAPBuilder.(MAPBuilder.java:72)
org.jboss.jbossts.xts.wsaddr.map.MAPBuilder.(MAPBuilder.java:78)
. . .

Yes, this relates to 621 and you can indeed get XTS 4.7 to run on AS 5.1 with JBossWS-CXF 3.2.1. However, you need to compile XTS using the correct switches because the implementation in 4.7 is dual source. The classes MAP, MAPBuilder etc come in two versions -- check the source code and you will see there are two directories containing implementations of these classes. The XTS sar can be built with the version which refers to the jbosssws AddressingProperties, AddressingBuilder etc or withthe one which refers to the cxf implementations. The version you have installed obviously refers to the JBossWS versions which are not present in your app server because you have replaced thhem with the cxf versions.

To fix this you need to rebuild your XTS sar to use the right code. Go to the XTS directory and type

ant -Dcxf.build=yes install

and then redeploy jbossxts.sar.

JBossWS migrated migrated the MAP classes into the WS/CXF stacks in 3.2.0. So, in XTS 4.8 the code is no longer dual source -- it just uses the implementations of MAP found in the JBossWS stack. So, when you move up to 4.8 the same XTS sar will work whichever stack is installed.