SOA Suite to Axis2 data being dropped

Question

We are in the process of migrating a WebLogic 10.3.5 web app to WebLogic 12.1.3 and we've run into an issue which we think might be related to web services security. The app uses Axis 1.5.6 to call out to a SOA Suite SOAP service (still running on WebLogic 10.3.5). When web service security is disabled, we get back the expected response:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:getNamesResponse 
    xmlns:ns2="http://www.example.com/ABC/Common" 
    xmlns:ns3="http://www.example.com/ABC/Profile">
    <ns3:OperatingName>
        <ns3:Number>123456789</ns3:Number>
        <ns3:Name>Company Name, Inc.</ns3:Name>
    </ns3:OperatingName>
</ns3:getNamesResponse>

But as soon as web service security is enabled (using Apache Rampart 1.5.2, Apache Neethi 2.0.5), we start receiving empty responses:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:getNamesResponse 
    xmlns:ns2="http://www.example.com/ABC/Profile" 
    xmlns:ns4="http://www.example.com/ABC/Common" />

The odd thing is that when looking through the SOA Suite console, the response out of SOA back to the web app (with security enabled) looks correct:

<message>
    <properties>
        <property  name="tracking.compositeInstanceId"  value="2110209"/>
        <property  name="tracking.ecid"  value="0058XKIkdpHFw00Fzzw0w00004Et005Kmk"/>
        <property  name="ws.wsu.id"  value="Body-Body_tTzuB5XmRNQPR7Y7"/>
    </properties>
    <parts>
        <part  name="getNamesResponse">
            <bp:getNamesResponse>
                <bp:OperatingName>
                    <bp:Number>123456789</bp:Number>
                    <bp:Name>Company Name, Inc.</bp:Name>
                </bp:OperatingName>
            </bp:getNamesResponse>
        </part>
    </parts>
</message>

No exceptions are logged. Has anyone else experienced and resolved these kinds of issues?

Answer 1

In the end, I resolved this issue by forcing the application to use JAR files that were bundled with the application, rather than ones provided by WebLogic. Using the Classloader Analysis Tool and some trial and error, I specified all of the JARs that were bundled with the application that were being used in the construction of the SOAP messages, and ended with something like this in weblogic-application.xml:

<wls:prefer-application-packages>
       <wls:package-name>com.ctc.wstx.*</wls:package-name>
       <wls:package-name>javax.mail.*</wls:package-name>
       <wls:package-name>javax.mail.event.*</wls:package-name>
       <wls:package-name>javax.mail.internet.*</wls:package-name>
       <wls:package-name>javax.mail.search.*</wls:package-name>
       <wls:package-name>javax.mail.util.*</wls:package-name>
       <wls:package-name>javax.wsdl.*</wls:package-name>
       <wls:package-name>javax.wsdl.extensions.*</wls:package-name>
       <wls:package-name>javax.wsdl.factory.*</wls:package-name>
       <wls:package-name>javax.wsdl.xml.*</wls:package-name>
       <wls:package-name>org.apache.oro.*</wls:package-name>
       <wls:package-name>org.apache.xerces.*</wls:package-name>
       <wls:package-name>org.apache.axiom.*</wls:package-name>
       <wls:package-name>org.bouncycastle.*</wls:package-name>
       <wls:package-name>org.bouncycastle.asn1.*</wls:package-name>
       <wls:package-name>org.bouncycastle.crypto.*</wls:package-name>
       <wls:package-name>org.bouncycastle.i18n.*</wls:package-name>
       <wls:package-name>org.bouncycastle.jce.*</wls:package-name>
       <wls:package-name>org.bouncycastle.math.*</wls:package-name>
       <wls:package-name>org.bouncycastle.mozilla.*</wls:package-name>
       <wls:package-name>org.bouncycastle.ocsp.*</wls:package-name>
       <wls:package-name>org.bouncycastle.openssl.*</wls:package-name>
       <wls:package-name>org.bouncycastle.util.*</wls:package-name>
       <wls:package-name>org.bouncycastle.voms.*</wls:package-name>
       <wls:package-name>org.bouncycastle.x509.*</wls:package-name>
       <wls:package-name>org.codehaus.stax2.*</wls:package-name>
       <wls:package-name>org.jaxen.*</wls:package-name>
       <wls:package-name>org.jaxen.dom.*</wls:package-name>
       <wls:package-name>org.jaxen.dom4j.*</wls:package-name>
       <wls:package-name>org.jaxen.expr.*</wls:package-name>
       <wls:package-name>org.jaxen.function.*</wls:package-name>
       <wls:package-name>org.jaxen.javabean.*</wls:package-name>
       <wls:package-name>org.jaxen.jdom.*</wls:package-name>
       <wls:package-name>org.jaxen.pattern.*</wls:package-name>
       <wls:package-name>org.jaxen.saxpath.*</wls:package-name>
       <wls:package-name>org.jaxen.util.*</wls:package-name>
       <wls:package-name>org.jaxen.xom.*</wls:package-name>
       <wls:package-name>org.slf4j.*</wls:package-name>
       <wls:package-name>org.slf4j.helpers.*</wls:package-name>
       <wls:package-name>org.slf4j.impl.*</wls:package-name>
       <wls:package-name>org.slf4j.spi.*</wls:package-name>
       <wls:package-name>org.apache.axis2.*</wls:package-name>
       <wls:package-name>org.opensaml.*</wls:package-name>
       <wls:package-name>org.apache.neethi.*</wls:package-name>
    </wls:prefer-application-packages>  

The Classloader Analysis Tool also helped us identity and eliminate duplicate and redundant JAR files, which we removed from the EAR file.