Using Axiom with payload caching off sometimes creates empty soap bodies [SWS-359]

[gregturn]

Jim Cummings opened SWS-359* and commented

It appears that if you're using Castor to marshal your responses, and you're using Axiom without payload caching, that the SOAP response comes back with an empty Soap Body. I did not try this with other Marshalling technologies like JAXB, etc, so I'm not sure if it is restricted to Castor only or not.

It looks like NonCachingPayload.DelegatingStreamWriter.writeEndDocument() never gets called at least when marshalling with Castor. Castor by default does not fire an endDocument SAX event (or close or flush for that matter). But if you call setMarshalAsDocument(true) on a castor marshaller it does call endDocument().

I just now worked around this with Castor by creating a simple subclass of CastorMarshaller like this below:
public class MyCastorMarshaller extends CastorMarshaller {
protected void customizeMarshaller(Marshaller marshaller) {
super.customizeMarshaller(marshaller);
marshaller.setMarshalAsDocument(true);
}
}

See this forum thread for additional details: http://forum.springframework.org/showthread.php?p=181732&posted=1#post181732

---

Affects: 1.5.2

Referenced from: commits b8effcb

[gregturn]

Arjen Poutsma commented

I could expose that property on the CastorMarshaller, so you can configure it in Spring config.

I'm open for nicer solutions, though.

[gregturn]

Chris Borrill commented

I am using org.springframework.ws.soap.axiom.AxiomSoapMessageFactory and org.springframework.oxm.jibx.JibxMarshaller. If I set the payloadCaching property of the AxiomSoapMessageFactory to false the SOAP body is empty, but if I set payloadCaching to true (the default) everthing works correctly.

[gregturn]

Jim Cummings commented

I wonder if maybe NonCachingPayload.DelegatingStreamWriter could more proactively detect the end of the payload element by watching the writeStartElement(), writeEndElement() and writeEmptyElement() events so that it would not need the writeEndDocument() to get called. It would probably need to support the possibility of nested elements in the payload having the same name as the root payload element, but it might could be done with a counter of starts vs ends for the root ele name. Dunno - just a thought.

[gregturn]

Arjen Poutsma commented

I had the same idea (counting elements) last night in bed. Great minds...

[gregturn]

Jim Cummings commented

Arjen - another related thing with this. I was working with a stax-based endpoint and saw similar issues with the empty body. I was able to temporarily work around that, but I noticed that when using StAX marshalling I also needed to call writeStartDocument() on my XMLStreamWriter. The DelegatingStreamWriter doesn't default the encoding to anything, and this was causing a NPE in ByteArrayDataSource.getXMLBytes() deep in axiom code during the msg.writeTo() call.

Could you default the encoding in case writeStartDocument() isn't called either? Thanks!

[gregturn]

Arjen Poutsma commented

I will add element depth counting. I don't think counting the writeEmptyElement() events is necessary, though, because that's just elementDepth + 1 -1. Also fixed the encoding bug, now defaults to UTF-8, like all XML should.

Could you check a recent snapshot (as of tomorrow) to check if things work now?

[gregturn]

Arjen Poutsma commented

Closing issues in 1.5.3

[gregturn]

Chris Borrill commented

Make sure you have no active interceptors if payload caching is set to false, since these will consume the message, as described here:

http://static.springframework.org/spring-ws/sites/1.5/apidocs/org/springframework/ws/soap/axiom/AxiomSoapMessageFactory.html

Good luck,
Chris