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.

Tags: Frameworks, Java, Maven
Filed under Deployment, Java | 9 Comments »