JiBX unmarshalling - DOM error

[Arjen Poutsma]

Arjen,

Is this why I must return a DOMSource in my endpoint's implementation of getResponse() ? Because I get exceptions when I try to return anything but that...i.e. StreamSource/SAXSource.

No, that's shouldn't be necessary. What Marshaller are you using?

[decrypt]

Actually I'm using AbstractSaxPayloadEndpoint

If I attempt to return anything but a DOMSource in getResponse(), I get exceptions on the server-side.

[Arjen Poutsma]

Hmm that sounds like a bug. Could you create an issue with the exact configuration and errors you get?

Thans,

[decrypt]

I will try...but I don't ever get to see the actual exception...it start trying to create a soap fault response and then it errors on the fact that there is already a response object created...so there may be two bugs at play here...

[decrypt]

I replaced WebLogic's XML related jars (Xerces, Xalan, xml-apis) and now i can return a SAXSource or a StreamSource just fine now.

[rwilcom]

One more question about an ealier response to this thread:
"There a two concrete implementations: SaajSoapMessage, which is based on a DOM tree, and AxiomSoapMessage, which is based on a StAX XMLStreamReader. ..."

So - on the server-side, in order for Spring WS to use Axiom one would have to set the system property for the SOAP factory to the AxiomSoapFactory, correct? And, once this system property is set Spring WS will use the StAX based streamer only - and therefore, you must use the SOAPActionEndpointMapping dispatcher/mapper so it looks at the SOAPAction header. The PayloadRootQNameEndpointMapping dispatcher/mapper will no longer work on "that" deployment since it relies on the DOM tree (and the system won't be using SAAJ)?

Is this a correct statement?

Ron

[Arjen Poutsma]

So - on the server-side, in order for Spring WS to use Axiom one would have to set the system property for the SOAP factory to the AxiomSoapFactory, correct?

No, you just have to change the SaajSoapMessageContextFactory in the application context to the AxiomSoapMessageContextFactory. That should be enough.

And, once this system property is set Spring WS will use the StAX based streamer only - and therefore, you must use the SOAPActionEndpointMapping dispatcher/mapper so it looks at the SOAPAction header. The PayloadRootQNameEndpointMapping dispatcher/mapper will no longer work on "that" deployment since it relies on the DOM tree (and the system won't be using SAAJ)?

No, the PayloadRootQNameEndpointMapping will work just fine, and so will the SoapActionEndpointMapping. It's just that the SoapActionEndpointMapping doesn't look in the contents of the message to dispatch it. That's why it's faster.
[/QUOTE]

Cheers,

[Arjen Poutsma]

I replaced WebLogic's XML related jars (Xerces, Xalan, xml-apis) and now i can return a SAXSource or a StreamSource just fine now.

Good news. Perhaps I should place a big warning on how to upgrade the XML libraries in the reference documentation. Seems to affect a lot of people.

Thanks!

[Arjen Poutsma]

The issue that was the original topic of this thread should now be fixed in subversion. You can get the sources from

https://svn.sourceforge.net/svnroot/...unk/spring-ws/.

I will upload a snapshot that will contain this functionality tomorrow.

[rwilcom]

Arjen,
Thanks for the fix! Was this an extensive update or a couple of blocks of code? Just curious, which classes and what areas were updated.

thanks again!
Ron