Stream closed before response read with WebServiceTemplate + Axis SAAJ Soap Messages

[BradHarvey]

Hi,

I'm converting an existing SAAJ client into a Spring-WS client. I got the following error when the template tries to check for the fault:

org.springframework.ws.soap.saaj.SaajSoapEnvelopeE xception: Could not access envelope: org.xml.sax.SAXParseException: Premature end of file.; nested exception is javax.xml.soap.SOAPException: org.xml.sax.SAXParseException: Premature end of file.

It appears that the messages are created lazily from the stream, but the stream is closed before that happens. I was able to work around the problem by forcing the message to be read in the readResponse method (using hasFault() in this case, there may be a better way):

HttpUrlConnectionMessageSender webServiceMessageSender = new HttpUrlConnectionMessageSender() {
protected void readResponse(HttpURLConnection connection, MessageContext messageContext) throws IOException {
if (connection.getResponseCode() == HttpURLConnection.HTTP_NO_CONTENT || connection.getContentLength() == 0) {
return;
}
TransportInputStream tis = null;
try {
tis = new HttpUrlConnectionTransportInputStream(connection);
messageContext.readResponse(tis);
/* workaround problem with lazy read - force message to be read before stream is closed */
messageContext.getResponse().hasFault();
}
finally {
if (tis != null) {
tis.close();
}
}
}
};


I'm using Java 1.4, Spring 1.0 M3, and my SAAJ implementation is Axis 1.4. I suspect the behaviour may not be evident for other SAAJ implementations.

I've shown the HttpUrlConnectionMessageSender here but same problem and workaround applies for the commons http client one.

Regards,
Brad.

[Arjen Poutsma]

Looks like a bug. Can you file a JIRA issue please?

Thanks for spotting this! The client-side support is pretty fresh, and I didn't have the opportunity to try it out on all servers.

[BradHarvey]

Sure thing - http://opensource.atlassian.com/proj.../browse/SWS-86.

I like the client side support - my spring-ws client code is less creepy than the saaj client code it replaced.

Some other thoughts/questions about the client side support:

Is the WebServiceMessageCallback the correct place to set a SOAPAction?

I've found I have to downcast to SoapMessage often and even SaajSoapMessage occassionally (so I could call setSaajMessage to replace the entire message in a WebServiceMessageCallback). Is this something you would expect? I think this is partly because I'm doing things with headers so getPayloadSource() and getPayloadResult() often aren't enough.

Should WebServiceGatewaySupport expose the template via the WebServiceOperations interface instead of the template class?

It wasn't immediately obvious to me from the javadoc how a FaultResolver was supposed to do its work (throw a runtime exception - demonstrated by SimpleFaultResolver).

[Arjen Poutsma]

Sure thing - http://opensource.atlassian.com/proj.../browse/SWS-86.

Thanks!

Is the WebServiceMessageCallback the correct place to set a SOAPAction?

Yes, it is. I should create a convenience implementation of the callback for this purpose.

I've found I have to downcast to SoapMessage often and even SaajSoapMessage occassionally (so I could call setSaajMessage to replace the entire message in a WebServiceMessageCallback). Is this something you would expect? I think this is partly because I'm doing things with headers so getPayloadSource() and getPayloadResult() often aren't enough.

yes, that's what I would expect. Most people are only interested in the source of the message. I also plan to add functionality similar to the EndpointInterceptors.

Should WebServiceGatewaySupport expose the template via the WebServiceOperations interface instead of the template class?

The gateway support class is modelled after JmsGatewaySupport, which also exposes a template. I basically copied the design.

It wasn't immediately obvious to me from the javadoc how a FaultResolver was supposed to do its work (throw a runtime exception - demonstrated by SimpleFaultResolver).

Yeah, I though about the runtime vs checked exception thing too, but since all of Spring's templates only throw runtime exceptions, I followed that lead. The only exception to the rule is the IOException, which I kept around.

[BradHarvey]

All sounds good, thanks for the feedback. Client interceptors would be nifty, especially if they could receive context from the caller (eg, a user/pass so the interceptor can add a security header).

Cheers,
Brad.

[Arjen Poutsma]

The issue is now fixed. Unfortunately, I had to change the interface of WebServiceTemplate in order to do so. Methods which return a Source could not be sustained, because the inputstream underlying the Source could already be closed. Instead, there is a SourceExtractor interface, which allows you to read from the source.

It works similar to JdbcTemplate, and its ResultSetExtractor.

[BradHarvey]

Great. I've had a quick look and it looks good, but I haven't had a chance to update and use it yet.

[decrypt]

Hmmm I think I just came accross the same issue.

[Arjen Poutsma]

This is solved in the snapshots.

[decrypt]

Ok. Any idea when M4 will be bundled up as a release?