Don't forget the content type

In one of our legacy projects all web services were exposed through SAAJ servlets; having to expose a new one we opted for a newer JAX-WS style, also thanks to everything that NetBeans gives you right out of the box.

So we created a new Web Service (you can check this tutorial to see how it is done) and wrote all the tests and code we needed. Everything went fine, until we tried to test the whole project (which should be mandatory before you commit).

At this point some of our old tests failed, all reporting the same error:

SAAJ0532: Absent Content-Type

The offending code builds a message that we use to test the parser:

private SOAPMessage buildMessage(String filename) throws IOException,  SOAPException {
  InputStream resourceAsStream =  this.getClass().getClassLoader().getResourceAsStream(basepath +  filename);
  MessageFactory messageFactory =  MessageFactory.newInstance();
  SOAPMessage message = messageFactory.createMessage(new  MimeHeaders(), resourceAsStream);
  return message;
}

At first it caught me off balance because our additions and changes went nowhere near the code related to the failure. Then it must be something related to the environment, which is the fact that NetBeans added a dependency on the JAX-WS 2.1 library that probably has some conflicts with the SOAP jars we use.

As some manual tests seemed to confirm that the application is working normally, we deferred the investigations (not for very much longer!) and simply fixed the test:

private SOAPMessage buildMessage(String filename) throws IOException,  SOAPException {
  InputStream resourceAsStream =  this.getClass().getClassLoader().getResourceAsStream(basepath +  filename);
  MessageFactory messageFactory =  MessageFactory.newInstance();
  MimeHeaders headers = new  MimeHeaders();
  headers.addHeader("Content-Type", "text/xml");
  SOAPMessage message = messageFactory.createMessage(headers,  resourceAsStream);
  return message;
}

And now an afterthought. The test failed, yet the application did not. Does this mean our test was wrong? Actually it only means that the previous library was more forgiving, because the test has proved useful for a long time (also spotting a regression). It is better to have a not-so-perfect test than none at all.

NetBeans and JAX-WS

A failing hard disk can be a positive thing: at least it forces you to learn new things. After fixing the project I just wrote about, I went straight to the next one, checked it out, fixed all the paths on the database configuration files (this time I was on the ball), cleaned and built, tested it and everything was fine. A big smile was spreading on my face, as now I could really go back to the real stuff.

Until I ran it.

20-mag-2010 17.53.23 com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized
INFO: WSSERVLET12: JAX-WS context listener initializing
20-mag-2010 17.53.27 com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized
GRAVE: WSSERVLET11: failed to parse runtime descriptor: javax.xml.ws.WebServiceException: Unable to create JAXBContext
javax.xml.ws.WebServiceException: Unable to create JAXBContext

(blah blah blah jabber jabber jabber blah blah blah)

Caused by: java.security.PrivilegedActionException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
my.wonderful.package.MyWonderfulClass is an interface, and JAXB can't handle interfaces.

(ariblah blah blah jabber jabber jabber blah blah blah)

Actually the blah blah part was much longer, but it left me quite disappointed. Everything had always worked fine, and we hadn't touched that codebase for quite a long time. It must have been something about configuration, but NetBeans didn't complain about missing references.

I googled for a while to get some clues, and everything I found required an intricate scaffolding over our classes. Too bad.

The only remaining culprit could only be NetBeans, as Marco pointed out - no, I won't pass to Eclipse, though. And that's final. Neither to Maven, at least for the time being :-)

Comparing a 6.7.1 installation with a 6.8 I found out that the first reported the JAX-WS 2.1 library in the dependencies of the project, while the latter the 2.2 version. At first I missed it, as the first place I checked was obviously the project.properties, that only reported a reference to the ${libs.jaxws21.classpath} variable, which was the version we were actually using. As setting up another project NetBeans kindly informed me that I was using JAX-WS 2.2 but the features I required needed the 2.1 version and I had to use the endorsing mechanism, I was quite ready for something like that, but it all passed by silently and I (wrongly) felt reassured.

I really had to double check... as I realized comparing the build.properties file used by the two IDEs, that referred to the same variable but had different path elements. What a fool! The more I find out, the less that I know...