This post is one of the series of posts about issues that occurred when we were using Mule2 in a real life project. As I wrote in my last post we were using CXF to call a webservice with Mule. After the issues we ran into as described in that article, we ended up with the folowing issue. The generated classes that are used for the XML to Java mapping has to be serializable. This is possible by using a binding file when generating the classes with Maven as described in the documentation here.
However, I haven’t been able to do this in my situation. And according to this post I am not the only one. So to keep the project moving I decided to make use of Metro JAX-WS instead of CXF, since this CXF thing had cost us enough of our precious time. With the Metro implementation we had it running in no time without any unexpected issues.

This post is one of the series of posts about issues that occurred when we were using Mule2 in a real life project. One of the things we had to do with Mule is communicating with a web service. This seemed not to difficult for a tool like Mule that is just build for interaction with other systems. This turned out to be different. We decided to use the CXF transport that comes standard with Mule. However, the web server we were calling was only able to ’speak’ via HTTP1.0 and therefor didn’t understand ‘chunking’. That led to the following error:
java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode
Continue reading…