Just a useful tip for passing in XJC command line parameters to wsimport

As the JAX-WS tools build on top of the JAX-B tools it is sometimes nice to be able to apply some of those customizations when building web services. This is quite easy it seems. Can't think of a use for it today; but is probably one of those things used to get out of a hole later on.

Consuming fault messages with JAX-WS

As I discovered whilst writing my presentation for Jazoon due to a programming error it was not possible to consume a SOAP Fault message using JAX-WS. You have to write a servlet instead. It looks like a fix for this is going into JAX-WS 2.1.5. This is good news although I can't seem to see the revision in the source code browser to check it will work.

JavaSpecialists.eu Patterns Course

I spent the end of last week on a Patterns course given by Dr Heinz of JavaSpecialists fame. Although I have used patterns for nearly all of my career it seem like a good oppotunity to revise what I though I already new. Not something you really get a chance to do day to day.

In general the course was well presented and Dr Heinz is a good speaker. I suspect that I could personally have done with more detail on different ways on implementing patterns; but we were in a mixed group so he could only go into so much detail. It was also useful to talk over the motivation for each pattern and it put a few things straight in my head.

We did the entire course using JDeveloper, and although I did log some bugs things are looking pretty stable these days. Dr Heinz did say he liked the expanded layout that is unique to the JDeveloper modelling tools. I wrote the original version of those, although the design idea is credit to Duncan Gittins, but the concept is still the same in the "new" generation modelers in JDeveloper 11.

Just to prove we were using JDeveloper in anger here is a nice picture of the Mememto pattern that we drew in class, in this case modelling virtual experimental rats:

Ah back from holidays, bat conference, gardening....

A nice relaxing time at the Quinta Da Bella Vista in Funchal, then a bit of gardening and a weekend at the UK National Bat Conference. (Lots of nice high end geeky ecology toys to play with)

Now to delete read the last of the 1k4 odd emails I had in my inbox this morning and then back to bugs. Although it has to be said that me team mates did a very good job indeed of making sure we are on top of things.

Capturing traffic from JAX-WS RI, or indeed any java client, on localhost

Although this post focuses on the HTTP Analyzer in JDeveloper, well because I work on it, this also contains information that is relavent to other testing tools such a tcpmon and SOAPUI.

Normally in a development situation where you have everything on the same box you can simply use "localhost" as the domain name. This has a lot of advantages when working in a source controlled environment as the same strings can be used on different machines. So in this scenario you have the client, some kind of HTTP monitoring proxy, and the server running on the same machine.

So when you start the client from inside of JDeveloper we set the right proxy environment settings; but you can expect them to look something like:

-Dhttp.proxyHost=localhost
-Dhttp.proxyPort=8988
-Dhttp.nonProxHosts=
-Dhttps.proxyHost=localhost
-Dhttps.proxyPort=8988
-Dhttps.nonProxHosts=

Now you would expect this mean that any request to any host will be sent via the proxy. But as noted in sun bug 6737819 the default ProxySelector will never proxy any requests to "localhost" even if you explicitly set "nonProxyHosts". This is of course a major pain for tools developers and users like.

Fortunately there is a workaround and that is to use "localhost.localdomain" instead. This is just a synomn for localhost and the proxy selector in java is not clever enough to recognize this as being the same as localhost. (Also I suspect it doesn't recognize :::1 or any of the other ipv6 localhost options)

When users get there sweaty hands on the next version of JDeveloper this is why we have moved to defaulting to "localhost.localdomain" rather than just plain old "localhost". Not because we are trying to be difficult or obtuse. :-)

Update:

Turns out this doesn't work so well on OS X. This is because the "/etc/hosts" file is missing localhost.localdomain entry. You can fix this by editing this file as root. ("sudo vi /etc/hosts") You need to alter the line:

127.0.0.1   localhost

to be

127.0.0.1   localhost localhost.localdomain

Please be carefull with this file, if you mess it up you machine may not boot properly. I have logged apple bug 6158676 to track this issue.

VW Polo Bluemotion 2

So my wife bought a VW Polo earlier on this year from the bluemotion range. We wanted something really quite fuel efficent I have have to say we are really quite pleased with how it lives up to the hype.

Based on the data provided by the onboard computer we average over 70 mpg, on longer motor way journeys it is not unheard of to average over 80 mpg. (Note these are UK not US MPG. Use a converter such as this one).

Remember this is the model with air-con and leather trims so it is not some eco-hay waggon. The variable speed turbo charger also means that is performs much better than you would expect from a diesel. Indeed I enjoy driving it more than my other sportier car in many ways.

And yes you could quite happily drive from London to Edinburgh on one tank of fuel, and avoid the congestion charge in the future due to its very low CO2 emissions.

More JAX-RI secrets @SchemaValidation

One of the nice things about the RI is that you keep on coming across nice little extensions in the com.sun.xml.* tree. Unfortunately many are not even documented so you only find they by reading the daily posts on the jax-ws forum.

Take for example com.sun.xml.ws.developer.SchemaValidation which allows you to validate incoming schemas. Many might say that this is a needless hit and duck typing is fine; but in certain debugging cases it would be nice to have some control over the validation failure process.

By default it uses com.sun.xml.ws.server.DraconianValidationErrorHandler but you can replace this with your own implementation to perform what-ever tracing and debuging you need. Normally you would have any control of this as the service would probably fail before the databinding stage.

@WebService
@ValidationErrorHandler(handler = CustomValidationFailureLogging.class)
public OrderProcessing
{
...
}

Well worth downloading the source code to see what goodies you are missing?