JAX-WS, CXF and SAAJ on Oracle Weblogic 10.3

Recently I had to get JAX-WS based webservices running on Weblogic 10.3. However instead of using the default Weblogic 10.3 stack (Metro), the Apache CXF stack had to be used. Why? We required SOAP over JMS capabilities and that is possible with CXF without much effort.

According to the CXF user documentation, a change to the weblogic-application.xml and packaging the CXF jars in the EAR should be enough for deploying on Weblogic.

    javax.jws.*

And if building with maven, the pom.xml would have the following dependencies defined :

    org.springframework
    spring
    2.5.6

    org.apache.cxf
    cxf-rt-core
    ${cxf.version}

        org.springframework
        spring-core

        com.sun.xml.bind
        jaxb-impl

        org.codehaus.woodstox
        wstx-asl

        org.apache.geronimo.specs
        geronimo-javamail_1.4_spec

        org.apache.geronimo.specs
        geronimo-annotation_1.0_spec

        org.apache.geronimo.specs
        geronimo-activation_1.1_spec

    org.apache.cxf
    cxf-rt-frontend-jaxws
    ${cxf.version}

        javax.xml.soap
        saaj-api

        com.sun.xml.messaging.saaj
        saaj-impl

        com.sun.xml.bind
        jaxb-impl

        org.codehaus.woodstox
        wstx-asl

        org.apache.geronimo.specs
        geronimo-javamail_1.4_spec

        org.apache.geronimo.specs
        geronimo-activation_1.1_spec

    org.apache.cxf
    cxf-rt-transports-http
    ${cxf.version}

        org.springframework
        spring-web

    org.apache.cxf
    cxf-rt-transports-jms
    ${cxf.version}

        org.springframework
        spring-jms

        org.apache.geronimo.specs
        geronimo-jms_1.1_spec

    org.apache.cxf
    cxf-rt-management
    ${cxf.version}

        org.springframework
        spring-core

    org.apache.cxf
    cxf-common-utilities
    ${cxf.version}

        org.springframework
        spring-core

        org.springframework
        spring-beans

        org.springframework
        spring-context

        org.apache.geronimo.specs
        geronimo-stax-api_1.0_spec

        org.apache.geronimo.specs
        geronimo-annotation_1.0_spec

However that setup was sufficient for the simplest of webservices. Our services used many more JAX-WS annotations to control parameter names, namespaces, operation names, soapbindings, WS-Addressing, etc. We also used the JAX-WS handler framework for custom processing of soap headers.
These type of webservices led to a scenario where JAX-WS Soap handlers defined in CXF had to process an incoming soap message whose first element in the soap body had a namespace prefix.

         
         World

When deploying these services on Weblogic, we ended up having to deal with SAAJ (SOAP with Attachments API for Java) problems caused by the combination of JAX-WS Soap handlers, CXF and a namespace prefixed element in the soap body.
The first error encountered was :

java.lang.UnsupportedOperationException: This class does not support SAAJ 1.1
at weblogic.webservice.core.soap.SOAPPartImpl.createElementNS(SOAPPartImpl.java:820)
at org.apache.cxf.staxutils.W3CDOMStreamWriter.writeStartElement(W3CDOMStreamWriter.java:132)
at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:118)

It turns out that Weblogic’s default SAAJ implementation, in package weblogic.webservice.core.soap, is flawed.
But there is a second "good" implementation that resides in the weblogic.xml.saaj package and supports SAAJ 1.3.
To enable the SAAJ 1.3 implementation, the system property

-Djavax.xml.soap.MessageFactory=weblogic.xml.saaj.MessageFactoryImpl

had to be added to the Weblogic startup script.
The next problem encountered demonstrated that the "good" implementation was not that good at all.

java.lang.AssertionError: UNIMPLEMENTED
at weblogic.xml.domimpl.NodeImpl.setPrefix(NodeImpl.java:173)
at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:724)
at org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:791)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:168)
at org.apache.cxf.jaxws.handler.soap.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:78)
at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.getOpQName(SOAPHandlerInterceptor.java:294)
at org.apache.cxf.jaxws.handler.AbstractJAXWSHandlerInterceptor.
setupBindingOperationInfo(AbstractJAXWSHandlerInterceptor.java:111)
at org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.
createProtocolMessageContext(SOAPHandlerInterceptor.java:235)

As a work around we had to fall back to the default SAAJ implementation present in the JSE6 runtime instead of using any of the Weblogic implementations. The JSE6 implementation can be enabled by setting the following system property in the Weblogic startup script:

-Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl

This works on both the SUN and the JRockit JVM. JAX-WS webservices running on the CXF stack and the default Weblogic stack can now be deployed in the same Weblogic domain without getting in each others way.
So far the work around appears to be working fine. Will keep you posted if any other problems may arise.