Announcement Announcement Module
Collapse
No announcement yet.
Unmarshalling problem moving a JAXB service from TC5.5 to Geronimo2.0.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unmarshalling problem moving a JAXB service from TC5.5 to Geronimo2.0.1

    I've hit trouble moving my JAXB-unmarshalled web service from Tomcat 5.5.23 to Geronimo 2.0.1; stack trace below. I used JDK6 on Linux for both TC and Geronimo.

    It's a simple web service with 2 operations with void return types, and uses Spring WS's PayloadRootAnnotationMethodEndpointMapping to route and unmarshal the messages to the correct method implementations.

    I stripped the .war down to use dummy empty implementations of everything, with no extra jar's, so that only the unmarshalling was causing a problem.

    I think it's because Geronimo contains e.g. the Axis 2 SAAJ implementation and it can't be overridden even when classloader priority is configured to be to the servlet context. There's no Axiom implementation included in WEB-INF/lib, which is confusing me - I can't see where the conflict is coming from. I generate my JAXB classes with wsimport on the command line and include them in WEB-INF/classes, so they don't include Geronimo machinery-maybe this is why.

    Is there a workaround? I've tried setting JAVA_OPTS in the geronimo.sh startup script to include
    -Djavax.xml.soap.MessageFactory=com.sun.xml.messagi ng.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl etc
    but it had no effect.


    16:33:04,183 WARN [SoapMessageDispatcher] Endpoint invocation resulted in exception - responding with SOAP Fault
    java.lang.ClassCastException: org.apache.axiom.soap.impl.dom.SOAPMessageImpl cannot be cast to org.apache.axiom.om.impl.dom.ElementImpl
    at org.apache.axis2.saaj.NodeImplEx.toSAAJNode2(NodeI mplEx.java:260)
    at org.apache.axis2.saaj.NodeImplEx.toSAAJNode(NodeIm plEx.java:181)
    at org.apache.axis2.saaj.SOAPElementImpl.getParentEle ment(SOAPElementImpl.java:723)
    at org.apache.axis2.saaj.SOAPElementImpl.getParentNod e(SOAPElementImpl.java:778)
    at com.sun.xml.bind.unmarshaller.DOMScanner.buildName spaceSupport(DOMScanner.java:159)
    at com.sun.xml.bind.unmarshaller.DOMScanner.buildName spaceSupport(DOMScanner.java:159)
    at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMS canner.java:100)
    at com.sun.xml.bind.v2.runtime.unmarshaller.Unmarshal lerImpl.unmarshal0(UnmarshallerImpl.java:288)
    at com.sun.xml.bind.v2.runtime.unmarshaller.Unmarshal lerImpl.unmarshal(UnmarshallerImpl.java:271)
    at javax.xml.bind.helpers.AbstractUnmarshallerImpl.un marshal(AbstractUnmarshallerImpl.java:107)
    at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmar shal(Jaxb2Marshaller.java:312)
    at org.springframework.ws.support.MarshallingUtils.un marshal(MarshallingUtils.java:54)
    at org.springframework.ws.server.endpoint.adapter.Mar shallingMethodEndpointAdapter.unmarshalRequest(Mar shallingMethodEndpointAdapter.java:145)
    at org.springframework.ws.server.endpoint.adapter.Mar shallingMethodEndpointAdapter.invokeInternal(Marsh allingMethodEndpointAdapter.java:135)
    at org.springframework.ws.server.endpoint.adapter.Abs tractMethodEndpointAdapter.invoke(AbstractMethodEn dpointAdapter.java:58)
    at org.springframework.ws.server.MessageDispatcher.di spatch(MessageDispatcher.java:211)
    at org.springframework.ws.server.MessageDispatcher.re ceive(MessageDispatcher.java:158)
    at org.springframework.ws.transport.support.WebServic eMessageReceiverObjectSupport.handleConnection(Web ServiceMessageReceiverObjectSupport.java:87)
    at org.springframework.ws.transport.http.WebServiceMe ssageReceiverHandlerAdapter.handle(WebServiceMessa geReceiverHandlerAdapter.java:57)
    at org.springframework.ws.transport.http.MessageDispa tcherServlet.doService(MessageDispatcherServlet.ja va:158)
    at org.springframework.web.servlet.FrameworkServlet.p rocessRequest(FrameworkServlet.java:475)
    at org.springframework.web.servlet.FrameworkServlet.d oPost(FrameworkServlet.java:440)
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:713)
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:806)
    at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:230)
    at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:175)
    at org.apache.geronimo.tomcat.valve.DefaultSubjectVal ve.invoke(DefaultSubjectValve.java:56)
    at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext. java:351)
    at org.apache.geronimo.tomcat.valve.GeronimoBeforeAft erValve.invoke(GeronimoBeforeAfterValve.java:47)
    at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:128)
    at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:104)
    at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:109)
    at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:563)
    at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:261)
    at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:844)
    at org.apache.coyote.http11.Http11Protocol$Http11Conn ectionHandler.process(Http11Protocol.java:581)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

  • #2
    Was with spring-ws-1.0.0

    Forgot to add, I'm using spring-ws-1.0.0. I don't know if upgrading will solve my problem because:
    - I haven't had the life force to build the new version
    - I didn't see a Geronimo compatibility fix explicitly in the change log

    Comment


    • #3
      Found a hack that works but is nasty

      As I thought, it's the Axis 2 SAAJ implementation inside Geronimo.

      I replaced the impl and api jars in the Geronimo repository with empty files, so that the deployer's dependency checker was fooled and rmi and the server started without complaining.
      Now my web service works. But I have a bad feeling about what I've just done to Geronimo - probably it will prevent me using CXF in the same server.

      Anyone got a better method? Or a fix for Spring-WS?

      Comment


      • #4
        It seems like it is a incorrect class cast inside the Axis2 SAAJ jars. It might be a good idea to let the Axis2 people know this.

        Comment

        Working...
        X