Do I need any other SOAP framework to run Spring Web Services?
You don't need any other SOAP framework to use Spring Web services, though it can use some of the features of Axis 1 and 2.

I get NAMESPACE_ERR exceptions when using Spring-WS. What can I do about it?

If you get the following Exception:

NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.

Most often, this exception is related to an older version of Xalan being used. Make sure to upgrade to 2.7.0.



Does Spring-WS run under Java 1.3?

Spring Web Services requires Java 1.4 or higher.


Does Spring-WS work under Java 1.4?

Spring Web Services works under Java 1.4, but it requires some effort to make it work. Java 1.4 is bundled with the older XML parser Crimson, which does not handle namespaces correctly. Additionally, it is bundled with an older version of Xalan, which also has problems. Unfortunately, placing newer versions of these on the class path does not override them. See this FAQ entry on the Xalan site, and also this entry on the Xerces site.

The only solution that works is to add newer versions of Xerces and Xalan in the lib/endorsed directory of your JDK, as explained in those FAQs (i.e.$JAVA_HOME/lib/endorsed). The following libraries are known to work with Java 1.4.2:


If you want to use WS-Security, note that the XwsSecurityInterceptor requires Java 5, because an underlying library (XWSS) requires it. Instead, you can use the Wss4jSecurityInterceptor.


Does Spring-WS work under Java 1.6?

Java 1.6 ships with SAAJ 1.3, JAXB 2.0, and JAXP 1.4 (a custom version of Xerces and Xalan). Overriding these libraries by putting different version on the classpath will result in various classloading issues, or exceptions in org.apache.xml.serializer.ToXMLSAXHandler. The only option for using more recent versions is to put the newer version in the endorsed directory (see above).


Why do the Spring-WS unit tests fail under Mac OS X?

For some reason, Apple decided to include a Java 1.4 compatibility jar with their JDK 1.5. This jar includes the XML parsers which were included in Java 1.4. No other JDK distribution does this, so it is unclear what the purpose of this compatibility jar is.

The jar can be found at /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar. You can safely remove or rename it, and the tests will run again.



What is SAAJ?

SAAJ is the SOAP with Attachments API for Java. Like most Java EE libraries, it consists of a set of interfaces (saaj-api.jar), and implementations (saaj-impl.jar). When running in a Application Server, the implementation is typically provided by the application server. Previously, SAAJ has been part of JAXM, but it has been released as a seperate API as part of the Java Web Service Developer Pack, and also as part of J2EE 1.4. SAAJ is generally known as the packagejavax.xml.soap.

Spring-WS uses this standard SAAJ library to create representations of SOAP messages. Alternatively, it can useApache AXIOM.


What version of SAAJ does my application server support?
Application ServerSAAJ Version
BEA WebLogic 81.1
BEA WebLogic 91.1/1.2*
BEA WebLogic 101.3**
IBM WebSphere 61.2
SUN Glassfish 11.3
JBoss 4.21.3***

* = See below.

** = See below.

*** = See below.

Additionally, Java SE 6 includes SAAJ 1.3.


I get a NoSuchMethodError when using SAAJ. What can I do about it?

If you get the following stack trace:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name '' defined in ServletContext resource [/WEB-INF/springws-servlet.xml]:
Invocation of init method failed;
nested exception is java.lang.NoSuchMethodError:
Caused by:

Like most J2EE libraries, SAAJ consists of two parts: the API that consists of interfaces (saaj-api.jar) and the implementation (saaj-impl.jar). The stack trace is due to the fact that you are using a new version of the API (SAAJ 1.3), while your application server provides an earlier version of the implementation (SAAJ 1.2 or even 1.1). Spring-WS supports all three versions of SAAJ (1.1 through 1.3), but things break when it sees the 1.3 API, while there is no 1.3 implementation.

The solution therefore is quite simple: to remove the newer 1.3 version of the API, from the class path, and replace it with the version supported by your application server.


I get an UnsupportedOperationException "This class does not support SAAJ 1.1" when I use SAAJ under WebLogic 9. What can I do about it?

WebLogic 9 has a known bug in the SAAJ 1.2 implementation: it implement all the 1.2 interfaces, but throws UnsupportedOperationExceptions when you call them. Confusingly, the exception message is This class does not support SAAJ 1.1, even though it supports SAAJ 1.1 just fine; it just doesn't support SAAJ 1.2. See alsothis BEA forum post.

Spring-WS has a workaround for this, we basically use SAAJ 1.1 only when dealing with WebLogic 9. Unfortunately, other frameworks which depend on SAAJ, such as XWSS, do not have this workaround. These frameworks happily call SAAJ 1.2 methods, which throw this exception.

The solution is to not use BEA's version of SAAJ, but to use another implementation, like the one from Axis 1, or SUN. In you application context, use the following:

<bean id="messageFactory" class="">
    <property name="messageFactory">
        <bean class="com.sun.xml.messaging.saaj.soap.MessageFactoryImpl"/>


I get an UnsupportedOperationException "This class does not support SAAJ 1.1" when I use SAAJ under WebLogic 10. What can I do about it?

Weblogic 10 ships with two SAAJ implementations. By default the buggy 9.x implementation is used (which lives in the package weblogic.webservice.core.soap), but there is a new implementation, which supports SAAJ 1.3 (which lives in the package weblogic.xml.saaj). By looking at the DEBUG logging when Spring Web Services starts up, you can see which SAAJ implementation is used.

To use this new version, you have to create a message factory bean like so:

<bean id="messageFactory" class="">
    <property name="messageFactory">
        <bean class="weblogic.xml.saaj.MessageFactoryImpl"/>


I get an IndexOutOfBoundsException when I use SAAJ under JBoss. What can I do about it?

The SAAJ implementation provided by JBoss has some issues. The solution is therefore not to use the JBoss implementation, but to use another implementation. For instance, you can use SUN's reference implementation like so:

<bean id="messageFactory" class="">
    <property name="messageFactory">
        <bean class="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl"/>


Does Spring-WS run on IBM WebSphere?

WebSphere bundles some libraries which are out-of-date, and need to be upgraded with more recent versions. Specifically, this includes XML-apis, Xerces, Xalan, and WSDL4J.

There are a couple of ways to upgrade these libraries, all using parent-last or application-first classloading.

  • Package the libraries as part of the WAR (in WEB-INF/lib), and run the web application with the parent-last (application-first) classloading.
  • Package the libraries as part of the EAR, add class-path entries to the manifest of the web application, and run the entire application with the parent-last classloading.
  • Create a new classloader in the WebSphere console, and associate the libraries with. Set this classloader to parent-last.
The last approach has the advantage of restricting the parent-last classloading to the conflicting libraries only, and not to the entire application.



Why does Spring-WS only support contract-first?

You can find the answer to this question on a separate page . Note that Spring-WS only requires you to write the XSD; the WSDL can be generated from that. The tutorial illustrates how.


How do I retrieve the WSDL from a Service? The &WSDL query parameter does not work.

The &WSDL query parameter is a way to get a WSDL of a class. In SWS, a service is generally not implemented as a single class, but as a collection of endpoints.

There are two ways to expose a WSDL:

  • Simply add the WSDL to the root of the WAR, and the file is served normally. This has the disadvantage that the "location" attribute in the WSDL is static, i.e. it does not necessarily reflect the host name of the server. You can transform locations by using a WsdlDefinitionHandlerAdapter.
  • Use theMessageDispatcherServlet, which is done is the samples. Every WsdlDefinition listed in the *-servlet.xml will be exposed under the bean name. So if you define a WsdlDefinition namedecho, it will be exposed as echo.wsdl (i.e.http://localhost:8080/echo/echo.wsdl).