JAXB conflict

With GlassFish Metro’s wsimport.sh script I generated Java interfaces and other supporting classes from a wsdl file. In a small test project it all worked like a charm.

Then I copied my code to an ATG project which needed my code. My testcase suddenly failed with a java.lang.NoSuchMethodError: javax.xml.bind.JAXBContext.newInstance(..
Ouch.

It took me some time to understand the problem. The problem is that the ATG das2007.1.jar contains a lot of external libraries. For instance Xerces or Xalan. However they changed the namespace to for instance atg.apache.xerces.. So conflicts are less likely.

But it also contains javax.xml.bind.JAXBContext. Grr this is JAXB 1 and my JAX-WS Metro stuff needs JAXB 2. Of course I can change the class-path order and I can do this in Eclipse, so my tests will work.
However ATG specification says that ATG-Required modules will be started up, in the order specified, before any modules started with ATG-Class-Path. So DAS will always be loaded before any custom jars according to the specification… I have not validated this yet, but I’m afraid that the specification is the way it works and thus my code will not work inside the Application container.

This will mean that this lovely solution will not work

And Spring, and CGLib, and Mozilla packages, and Sun packages and IBM BSF, Apache Commons etc etc?

IBM BSF? The Bean Scripting Framework got promoted to Jakarta in 2002 and for some time now it has an Apache namespace and not an IBM namespace. That is some old stuff in the das jar. This is taking “If it aint broke don’t fix it” to a new level.
And does anybody else find it funny that an ATG jar, especially the one containing Nucleus, contains Spring classes. Ok it is just the Spring AOP classes, but still. Nucleus and Spring IOC are birds of a feather. These are just some of the examples of some of the embedded classes.

Why bundle libraries?

I sort of understand that you want to control the versions of external libraries you need, but bundling them in stealth mode is bad practice in my opinion. Especially if you are a framework like ATG. Frameworks don’t live in a vacuum, they need extra custom code and thus clashes are likely. I rather see the jars and documentation for which library versions your product is tested.

I’m not really fluent in Ruby but Ruby’s require_gem with the version argument sounds like a nice feature.

I decided to go the JAX-WS route, since this appears to become a standard: JSR 224. Java 6 will have it as a feature.

The JAX-WS choice does mean that Axis2 cannot be used. I don’t really mind since I’ve experienced some real pain there in previous projects. I’m not the only one. Hani sums it up nicely.

JAX-WS contenders

A bit of googling looked like the contenders are:

• JBossWS
• CXF
• Metro

Because it seemed I was the first one using the here unnamed web services, I first decided to play with Amazon web services, because documentation and examples for Amazon web services are widely available.
This excellent article explains how to use AWS ECS with Metro and with CXF. I did not go for the ANT route and used wsdl2java and wsimport.sh. to generate the Java code.

JBossWS

JBossWS seems a bit tied to JBoss 5 and because I need to work with JBoss 4.0.5, I ignored that option.

Since I will consume a webservice, I feel that JBossWS could still be viable. However the pain I had converting the CXF Geronimo stuff to JBoss stuff (more on that later), confirmed my suspicion that JBossWS would not be an easy route in my environment. This is not to say that when using JBoss 5, you cannot have total bliss with JBossWS.

CXF

CXF is still an Apache incubator project. It is a merge of XFire and Celtix. The wsdl2java script did run without problems. When you want to use the generated code you need the following jars, according to the documentation:

• cxf.jar
• commons-logging.jar
• geronimo-activation.jar (Or the Sun equivalent)
• geronimo-annotation.jar (Or the Sun equivalent)
• geronimo-javamail.jar (Or the Sun equivalent)
• neethi.jar
• jaxb-api.jarv
• jaxb-impl.jar
• stax-api.jar
• XmlSchema.jar
• wstx-asl.jar
• xml-resolver.jar
• jaxws-api.jar
• saaj-api.jar
• saaj-impl.jar

I could call ECS without any problems, however the Geronimo jars were a thorn in my eye, I tried to replace them with a JBoss equivalent. I entered a world of pain. With jboss.org.lang.Annotation problems (update JBossWS) and then javax.annotation.PostConstruct problems.
So I concluded that it was not possible to remove the Geronimo jars. Upgrading to the latest JBossWS implementation got me dependent on JBoss 5 it seemed, which is no option.
So if you can live with Geronimo jars and 15 jars in total, give or take a few (removing 1 or 2 seems not to break anything) then you are good to go.

Although I ran into the same observation as Glen Mazza. jaxws:enableWrapperStyle not working in CXF

Metro

I downloaded the standalone version instead of a complete Glassfish distribution.
I had to alter the wsimport.sh script, because WSImport needs JAF. I added the activation.jar from the JBoss distribution to the classpath in the wsimport.sh script. The generated code enabled me to call ECS without any problems.
I needed the following jars:

• webservices-extra.jar
• webservices-rt.jar
• webservcies-api.jar

Compared to CXF, Metro just seems more environment friendly. Of course this could be complete rubbish, since those three jars can be completely bloated with everything but the kitchen sink.

For now I will use Metro and see how this will go.