Подтвердить что ты не робот

Сброс данных SOA Suite на Axis2

Мы пытаемся перенести веб-приложение WebLogic 10.3.5 в WebLogic 12.1.3, и мы столкнулись с проблемой, которая, по нашему мнению, может быть связана с безопасностью веб-служб. Приложение использует Axis 1.5.6 для вызова службы SOA Suite SOAP (все еще работает в WebLogic 10.3.5). Когда защита веб-службы отключена, мы возвращаем ожидаемый ответ:

<?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>

Но как только включена защита веб-сервиса (с использованием Apache Rampart 1.5.2, Apache Neethi 2.0.5), мы начинаем получать пустые ответы:

<?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" />

Странно, что при просмотре консоли SOA Suite ответ SOA на веб-приложение (с включенной безопасностью) выглядит правильно:

<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>

Никакие исключения не регистрируются. Кто-нибудь еще испытал и разрешил эти проблемы?

4b9b3361

Ответ 1

В конце концов, я решил эту проблему, вынудив приложение использовать файлы JAR, которые были в комплекте с приложением, а не предоставленные WebLogic. Используя "Инструмент анализа классов" и некоторые пробные версии и ошибки, я указал все JAR-серверы, которые были связаны с приложением, которое были использованы при построении SOAP-сообщений и закончились чем-то вроде этого в 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>  

Инструмент анализа Classloader также помог нам идентифицировать и устранить дубликаты и избыточные JAR файлы, которые мы удалили из файла EAR.