Now I know that XTS doesnt support https yet but it 'might' work. Some seem to get further than I do.
Err, not exactly. XTS works fine with https, just as well as it does with http. The only problems we have had reported were outside the scope of the XTS code in the HTTP transport layer.
The deal with 'support' is that XTS is not yet included as a part of the JBoss EAP platform for which support contracts are available. So, until AS 5.0 any help you get with XTS problems is on this forum, for free and best-effort.
That said, please continue trying to get this to work and I'll keep reading this thread in case I can contribute. However, currently it looks to me that the problem is to do with certificates, not the XTS code.
I managed to move beyond a 403 now to get a 400 at the same point. I moved past this by importing the certificates (mine/the ms clients) into the trust store rather than just the key store. I have also read that the MSDTC is very strict on what the certifcates shoud contain - I am going to try re-rolling a new certificate.
Trouble is I can only find one page regarding this error on the whole internub.
Yes, I understand about the support issues, I apprieciate any small bits and the time people spend on this forum.
In the meantime this is the curent location of the problem.
9:53:08,341 INFO [STDOUT] http-126.96.36.199-8081-1, WRITE: TLSv1 Application Data, length = 345
09:53:08,341 INFO [STDOUT] http-188.8.131.52-8081-1, WRITE: TLSv1 Application Data, length = 1806
09:53:08,387 INFO [STDOUT] http-184.108.40.206-8081-1, READ: TLSv1 Application Data, length = 131
09:53:08,419 ERROR [STDERR] bookSeats: Participant enrolment failed
09:53:08,419 ERROR [STDERR] com.arjuna.wst.SystemException: Sender[[com.arjuna.webservices.transport.http.HttpClient_4] - Invalid response code returned: 400]
09:53:08,419 ERROR [STDERR] at com.arjuna.mwlabs.wst.at.remote.TransactionManagerImple.registerParticipant(TransactionManagerImple.java:215)
09:53:08,419 ERROR [STDERR] at com.arjuna.mwlabs.wst.at.remote.TransactionManagerImple.enlistForDurableTwoPhase(TransactionManagerImple.java:77)
09:53:08,419 ERROR [STDERR] at com.arjuna.xts.nightout.services.Restaurant.RestaurantServiceAT.bookSeats(RestaurantServiceAT.java:69)
09:53:08,419 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
09:53:08,419 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
09:53:08,419 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
09:53:08,419 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
09:53:08,419 ERROR [STDERR] at org.jboss.wsf.container.jboss42.DefaultInvocationHandler.invoke(DefaultInvocationHandler.java:102)
09:53:08,419 ERROR [STDERR] at org.jboss.wsf.container.jboss42.DefaultInvocationHandlerJAXRPC.invoke(DefaultInvocationHandlerJAXRPC.java:57)
Again if I solve this problem I will report back here.
Well, we have just managed to get this working over SSL with all services working over https (using the tomcat ssl connector).
Main problems encountered were :
1) Getting configured certificates working. If not you would fail at handshaking stage 'pxix building failed' or would get a 403 error. You need to have on the java side a certificate (self signed is fine) which you have supplied to the MS client and they have trusted. In return you need their cert and to trust their CA cert (or the same if self signed). CA cert should be in your trust store and personal cert in your keystore. This is actually not that difficultas long as you trust each others certificates correctly.
2) Ensure the subject of your certificates are the same as your hostname and use hostnames throughout your addresses and not IP addresses.
We then arrived at 400 errors. As far as we can tell this means the certificate stuff is fine. This was down to a bug in a similar vein to :
Basically the MS DTC send messages with an address component which looks like:
(Note I had to remove the open and closing bracket to get that to post right....)
The Java XTS sends messages around which look like this :
Essentially when XTS responds to the MS DTC the address was getting a bit mangled as it was storing the 'From' Endpoint reference for a later response:
<wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing">https://full.hostname/WsatService/Registration/Coordinator/</wsa:To>
Note the xmlns:xmlns. It appears when an attribute is not qualified it uses the default xmlns namespace and then MSDTC doesnt like it. Hence we have to stop this prefixing of xmlns.
In order to get out prototype working, I performed the following code modification to WS-C.jar in SP7. This was just a temporary hack and not meant as a real fix! Modified bit in bold.
protected final void parse(final XMLStreamReader in)
final int attributeCount = in.getAttributeCount() ;
for(int count = 0 ; count < attributeCount ; count++)
QName attributeName = in.getAttributeName(count) ;
final String attributeValue = in.getAttributeValue(count) ;
if (attributeValue.equals("http://schemas.xmlsoap.org/ws/2004/08/addressing") &&
attributeName.getLocalPart() == "xmlns")
attributeName = new QName("", "xmlns");
putAttribute(in, attributeName, attributeValue) ;
It probably wrong....But it works and there seems to have been a lot of others stumped on this problem with no real solutions.
Next step is to get databases involved.