JAX-WS, CXF und SAAJ auf Oracle Weblogic 10.3

Vor kurzem musste ich JAX-WS-basierte Webservices unter Weblogic 10.3 zum Laufen bringen. Anstelle des standardmäßigen Weblogic 10.3 Stacks(Metro) musste jedoch der Apache CXF Stack verwendet werden. Und warum? Wir benötigten SOAP-over-JMS-Funktionen und das ist mit CXF ohne großen Aufwand möglich.

Laut der CXF-Benutzerdokumentation sollte eine Änderung der weblogic-application.xml und das Verpacken der CXF-Jars in der EAR für die Bereitstellung unter Weblogic ausreichen.

  javax.jws.*

Und wenn Sie mit Maven bauen, würden in der pom.xml die folgenden Abhängigkeiten definiert sein:

  org.springframework
  Frühling
  2.5.6

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

  org.springframework
  Federkern

  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-anmerkung_1.0_spec

  org.apache.geronimo.specs
  geronimo-aktivierung_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-aktivierung_1.1_spec

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

  org.springframework
  spring-web

  org.apache.cxf
  cxf-rt-transporte-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
  Federkern

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

  org.springframework
  Federkern

  org.springframework
  Frühlingsbohnen

  org.springframework
  spring-kontext

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

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

Diese Einrichtung war jedoch für die einfachsten Webservices ausreichend. Unsere Dienste verwendeten viele weitere JAX-WS-Annotationen zur Steuerung von Parameternamen, Namespaces, Operationsnamen, Soapbindings, WS-Addressing usw. Außerdem verwendeten wir das JAX-WS Handler-Framework für die benutzerdefinierte Verarbeitung von Soap-Headern. Diese Art von Webservices führte zu einem Szenario, in dem in CXF definierte JAX-WS Soap-Handler eine eingehende Soap-Nachricht verarbeiten mussten, deren erstes Element im Soap-Body ein Namespace-Präfix enthielt.

         
  Welt

Bei der Bereitstellung dieser Dienste unter Weblogic hatten wir schließlich mit SAAJ-Problemen (SOAP with Attachments API for Java) zu kämpfen, die durch die Kombination von JAX-WS Soap-Handlern, CXF und einem Element mit vorangestelltem Namespace im Soap-Body verursacht wurden. Der erste Fehler, der auftrat, war : 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) Es stellt sich heraus, dass die Standard-SAAJ-Implementierung von Weblogic im Paket weblogic.webservice.core.soap fehlerhaft ist. Es gibt jedoch eine zweite "gute" Implementierung, die sich im Paket weblogic.xml.saaj befindet und SAAJ 1.3 unterstützt. Um die SAAJ 1.3-Implementierung zu aktivieren, muss die Systemeigenschaft -Djavax.xml.soap.MessageFactory=weblogic.xml.saaj.MessageFactoryImpl musste dem Weblogic-Startskript hinzugefügt werden. Das nächste Problem, das auftrat, zeigte, dass die "gute" Implementierung gar nicht so gut war. 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) Als Ausweichlösung mussten wir auf die standardmäßige SAAJ-Implementierung zurückgreifen, die in der JSE6-Laufzeitumgebung vorhanden ist, anstatt eine der Weblogic-Implementierungen zu verwenden. Die JSE6-Implementierung kann durch Setzen der folgenden Systemeigenschaft im Weblogic-Startskript aktiviert werden: -Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl Dies funktioniert sowohl auf der SUN als auch auf der JRockit JVM. JAX-WS-Webservices, die auf dem CXF-Stack und dem Standard-Weblogic-Stack laufen, können jetzt in derselben Weblogic-Domäne eingesetzt werden, ohne sich gegenseitig zu behindern. Bisher scheint die Umgehung gut zu funktionieren. Ich werde Sie auf dem Laufenden halten, falls weitere Probleme auftreten sollten.