CXF gotchas

We have finished converting some existing web services based on the old XFire framework to the new CXF framework. During this transition, we encountered many bumps and bruises along the way. I’d like to share some of the major issues to prevent others from feeling the same pain.

XFire and CXF are frameworks that allow one to easily write and deploy SOAP web services using the Spring framework. In majority of the cases, one would write regular java classes, annotate the web service methods as such, and configure the beans through Spring and voila, SOAP web services.

First, CXF is a relatively new project and is kept as an Incubator project at Apache. CXF uses a lot of new supporting technologies. This can be a problem if you’re deploying to an older environment where you may be required to use older versions of jars. In particular, XML parsers have always been problematic in Java because you can’t guarantee which implementation is being picked up first in your classpath. I came across a JAXP implementation problem where I got UnsupportedOperationException:This parser does not support specification null “version” null. This took a while to nail down because we were inserting our own application “version” element into the SOAP header. I was under the assumption that our problem had to do with an improper namespace. Eventually, the fix was to upgrade to xercesImpl-2.9.1.jar and the UnsupportedOperationException disappeared.

Speaking of namespace problem. We could not get our web service methods to work due to an unknown namespace “ns2” problem. We are using Aegis as our data binding technology for CXF and it may be due to a bug in Aegis since they don’t really support it anymore. The workaround we found was to set the SOAPBinding to be ParameterStyle.BARE and limit ourselves to a single parameter.

Another problem we encountered was in the documentation. According to the docs, one should be able to configure the underlying Client HTTP Transport to modify properties such as ConnectionTimeout or Keep-Alive, etc., strictly through the Spring XML configuration. However, this does not seem to be the case. We had to modify these properties dynamically in the code.

And then there were Websphere deployment problems. A documented workaround for AppServerGuide:Websphere does not work as advertised. Do *NOT* make “classes loaded with application class loader first”. Using AIX and Websphere 6.1.0 we encountered numerous SOAP and Serialization exceptions due to our application jars being picked up by the application server itself. It seemed like the Node Manager used our classpath and caused all hell to break loose.

One last AIX – Websphere problem was caused by the old libraries used by Websphere. We were using methods defined in the DOM Level 3 API in our application code. Apparently in Websphere on AIX, we have a XML parser that does not have Level 3 support. We tried swapping parser implementations and another classpath hell broke loose. So don’t do it!

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply