SOA Suite to Axis2 data being dropped
Asked Answered
L

1

13

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?

Laboured answered 19/10, 2015 at 18:54 Comment(5)
Have you checked logs for errors ? Weblogic has its own XML libs, so it might be a library conflict..Woosley
Are you using the same soap request ? I understand that should has new tags for security (WS - Security 1.1, etc.) And probably the SOA internal client is hitting directly to your endpoint (bypassing the security layer).Asteria
The logs don't indicate a failure of any kind. The SOAP client code hasn't changed, nor have the versions of the client components as outlined above (rampart, etc.). It seems to me that is SOA was bypassing security, then we would get a security exception. Everything seems to work from a security standpoint. It's simply the response XML that gets dropped.Laboured
What do you get if calling SOA Endpoint from SoapUi or another tool ? I want to check if the response you see in Enterprise Manager console is really what is sent..Woosley
I would turn up logging on the WSM in your SOA Suite server. The reason being that your BPEL or mediator might show that everything is fine, but your Policy on WSM may be out of whack.Logroll
L
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.

Laboured answered 1/3, 2016 at 14:38 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.