Chris Harcourt

I’ve been working on a project using Spring WS recently. During development I run/test webapps using the Maven Jetty plugin. All was well, everythings works as expected, and I was at a stage where I needed to deploy on a Tomcat 6 server for some larger scale testing. In the past I have had no issues moving from Jetty to Tomcat so, possibly foolishly, I was not expecting any this time…

After deploying to Tomcat the web frontend worked fine, but the web services did not. A quick look at the logs revealed lots of exceptions relating to SAAJ. The top of the stacktraces were:

org.springframework.ws.soap.saaj.SaajSoapMessageException: Could not write message to OutputStream: Error during saving a multipart message; nested exception is com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Error during saving a multipart message
at org.springframework.ws.soap.saaj.SaajSoapMessage.writeTo(SaajSoapMessage.java:122)
...
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Error during saving a multipart message
at com.sun.xml.internal.messaging.saaj.soap.MessageImpl.saveChanges(MessageImpl.java:1126)
at org.springframework.ws.soap.saaj.Saaj13Implementation.writeTo(Saaj13Implementation.java:264)
at org.springframework.ws.soap.saaj.SaajSoapMessage.writeTo(SaajSoapMessage.java:118)
...
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to get header stream in saveChanges:
at com.sun.xml.internal.messaging.saaj.soap.MessageImpl.saveChanges(MessageImpl.java:1103)
...
Caused by: java.io.IOException
at com.sun.xml.internal.messaging.saaj.soap.impl.EnvelopeImpl.output(EnvelopeImpl.java:298)


I’m running on Java 6, which contains it’s own SAAJ implementation, so I was fairly sure it wasn’t a problem with the libraries in the application itself. So, I hit google for a couple of hours in hope of finding a solution. I didn’t find anything which mentioned this issue specifically, but the gist I was getting pointed towards a problem with the XML parser.

In desperation I tried including various bits of Xerces in the application’s WAR (I know Java 6 has a built in parser, but I figured it was worth a try). This didn’t work, and in fact caused even more errors. This problem was really starting to annoy me…

It occurred to me that it could be something about the configuration of the server which runs Tomcat. If it all works fine on my workstation it must be the server, right? So I put pulled down a copy of the project onto the server and ran it using the Maven Jetty plugin. Lo and behold, it worked flawlessly. Maybe it’s a Tomcat issue then? To verify this I installed Tomcat on my workstation and ran the app there. Same problem - it muct be Tomcat then. OK, time to hit google again.

…many frustrating hours pass…

Eventually I found a page which mentioned errors simmilar to mine, so I tried it’s solution… and … thank the Lord - it works! What was this magical solution? Putting a copy of Xerces and Xalan in the Tomcat’s ‘endorsed’ lib directory. Annoyingly simple. Why does this work? I’m not certain, but apparently the versions of Xerces and Xalan which Tomcat ships with don’t play well with the SAAJ implementation in Java 6 (this might well be wrong…). The important thing is it fixed the problem.

For reference (in case this problem appears for anyone else) I am using: Java 1.6.0_06, Tomcat 6.0.16, Spring 2.5.4 and Spring WS 1.5.2. The jars I put in %TomcatHome%/common/endorsed to fix the problem were xalan-2.7.0 and xercesImpl-2.8.1.

I am now back to development nirvana - balance has been restored.