So I want to use the JAX-WS RI with JDK 6, so I need the endorsed directory right?

So JDK6u4 comes with JAX-WS RI 2.1.3 so you don't really need to worry about downloading and instally the RI? Right, well there is some slight confusion in that the sun extensions to the JAX-WS standard, for example WSBinding, are repackaged into a different package path for inclusion into the JDK. Any server is going to use the RI version of these classes without the "internal" in the package path.

You can't just add the RI classes to the source path and have it work as the javax.xml.ws.spi.Provider is hard coded to use the "internal" jdk version of the RI. So lets look at the following options:

1. JDK 6_u4

In this case the provider uses the value of the constant javax.xml.ws.spi.Provider.DEFAULT_JAXWSPROVIDER which is "com.sun.xml.internal.ws.spi.ProviderImpl".

2. JDK 6_u4 + JAX-WS RI in endorsed

In this case the provider uses the value of the constant javax.xml.ws.spi.Provider.DEFAULT_JAXWSPROVIDER in endorsed version of the jar which is "com.sun.xml.ws.spi.ProviderImpl".

This is what the RI documentation tells you; but you only need to do this if the RI version doesn't match that of the JDK.

3. JDK 6_u4 + META-INF/services/javax.xml.ws.spi.Provider

If you are using something like weblogic that there will be an entry on the classpath, for example in weblogic.jar, that contains an service entry with the above path. In the weblogic case the first services contains the text "weblogic.wsee.jaxws.spi.WLSProvider". This extends "normal" RI classes so you get the classes you expect.

This does present a workaround if you want the RI; but can't control the endorsed directories (Perhaps with WebStart). You can simply create the service entry on the classpath in your own jars with the "com.sun.xml.ws.spi.ProviderImpl" class as its only content. This will force the external RI implementation to be used.

Finally it is worth saying that there is nothing wrong with using the RI classes in the JDK, I just find it tidier to use the same set of package names in all cases.

Updated Asynchronous Web Service slides from Jazoon'08

It contain a whole bunch of updates from the JavaOne'08 version. In particular a section on rolling your own version of part of the @AsyncWebService proposal using the RI.

Controlling thread pooling for JAX-WS Async Client API

I might previously have said <cough /> that there is no way to control the number of threads used when using the JAX-WS async client API. Turns out that perhaps I was just being a little bit dense and hadn't noticed the setExecutor(...) method on the Service interface. This doesn't solve all of your problems though as you need to set this for each service instance (This is not really a good thing in a server environment); but if of course more controllable in the JSE case.

Now if I had only worked this out before I flew to Zurich.... then I wouldn't have had the mistake in the slide. Oh well.

Paper accepted for Jazoon'08, erm tommorrow.

I will be presenting a revised version of my async presentation tomorrow at Jazoon'08 in Zurich Switzerland. Just filling in for another Oracle bod who couldn't make it at the last minute this time. Queue a day of feverishly trying to remember my lines!

SCA and Asynchronous Services

Ran over a nice little article on InfoQ about SCA and asychronous services. Interesting to see more real example of the SCA-Java binding; but the standard still looks a little bit "old fashioned" when compared to say WebBean or Spring 2.x.

Connection refused confusion

I was working with a web service today trying to resolve a bug in the HTTP Analyzer that resulted in a "Connection Refused" error coming back from the server. I spent ages trying to connect to the server in different ways using telnet and other WS testing tools. They all seemed to work; but I couldn't work out why a simple socket connection would fail just for JDeveloper.

It turned out that after much nashing of teeth that there was a problem with the SOAPAction header. It was being set to "null" rather than just "". So the connection was being refused for a faulty header rather than the socket not being set up. The confusion came because you get the same error code back from a proxy in both cases. At least in the case of this particular server. (It was not clear what technology they were using to host the services underneath)

Still fixed the analyzer, just glad it finally clicked as to what was going on.

Promotion

Found out yesterday that I have been promoted to the heady heights of "IC5". (Also know as "Senior Principle Software Engineer" in the UK or "Consulting Member of Technical Staff" in Oracle US) This has been a long term goal of mine, slightly set back when I switched from UML to web services and had to start in a new area. It is also something you need the support of a bunch of good people to achieve both in day-to-day and in terms of references. It might also interest an outsider to know that some of these reference have to come from outside not just your group but also in some cases from outside Oracle.

So big thanks to my co-team members past and present, Alan Davis, Alan Gibson and Sheen Brisals. And of course my direct managers John Blair and Dai Clegg for supporting me in the process of gathering the evidence to back the promotion! And for those outside of my group for providing good references. (Money is in the post etc.)

Now back to what ever I was doing the day before yesterday. As is generally the case you find you are already doing the job by the time you get the promotion.