[SWS-359] Using Axiom with payload caching off sometimes creates empty soap bodies Created: 21/May/08  Updated: 21/Aug/08  Resolved: 06/Jun/08

Status: Closed
Project: Spring Web Services
Component/s: Core
Affects Version/s: 1.5.2
Fix Version/s: 1.5.3

Type: Bug Priority: Major
Reporter: Jim Cummings Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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



 Comments   
Comment by Arjen Poutsma [ 21/May/08 ]

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

I'm open for nicer solutions, though.

Comment by Chris Borrill [ 21/May/08 ]

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.

Comment by Jim Cummings [ 21/May/08 ]

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.

Comment by Arjen Poutsma [ 21/May/08 ]

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

Comment by Jim Cummings [ 22/May/08 ]

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!

Comment by Arjen Poutsma [ 06/Jun/08 ]

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?

Comment by Arjen Poutsma [ 21/Jul/08 ]

Closing issues in 1.5.3

Comment by Chris Borrill [ 21/Aug/08 ]

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

Generated at Mon Dec 18 05:13:22 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.