axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Rodriguez (JIRA)" <>
Subject [jira] Commented: (AXIS2-795) Returning a MTOM message causes IOException (closed stream)
Date Fri, 31 Aug 2007 15:28:31 GMT


Alex Rodriguez commented on AXIS2-795:

I would like to see this fixed as well. Cleanup should not be called on the transport sender
because the content from the underlying input stream encapsulated within the returned OMElement
may not have been fully read yet. This happens in the case of large attachments or soap messages
sent over a chunked input stream.

> Returning a MTOM message causes IOException (closed stream)
> -----------------------------------------------------------
>                 Key: AXIS2-795
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: databinding
>    Affects Versions: 1.0
>         Environment: JDK 1.4.2_06
>            Reporter: Wolfram Kaiser
>            Assignee: Thilina Gunarathne
> When accessing an attachment sent via MTOM on the client side I get the following exception:
> javax.mail.MessagingException: Error in input stream;
nested exception is:
> Attempted read on closed stream.
>     at org.apache.axiom.attachments.Attachments.getPart(
>     at org.apache.axiom.attachments.Attachments.getNextPart(
>     at org.apache.axiom.attachments.Attachments.getPart(
>     at org.apache.axiom.attachments.Attachments.getDataHandler(
>     at
>     at
> The client stub was generated using the default / no data binding (-> direct Axiom
access). I believe the error is in the generated stub:
> public echoPdf( param48) throws
java.rmi.RemoteException {
> ...
>     _messageContext.getTransportOut().getSender().cleanup(_messageContext);
>     return ( object;
> }
> The cleanup() seems to close the InputStream for the PDF/attachment while the attachment
has not been loaded in Axiom. Thus, when accessing the attachment in the OMElement returned
by MyStub.echoPdf() the aforementioned exception is thrown. I would argue that the pull mechanism
of Axiom fails in cases where the associated InputStream has been closed while the generated
stub has done its processing already.
> The following simple - but rather ugly - work-around seems to solve the problem:
> public echoPdf( param48) throws
java.rmi.RemoteException {
> ...
> omElement = ( object;
>     // retrieving the content of a OMTextNode will load the associated data so it can
be accessed
>     // even after the InputStream from this web service call has been closed.
>     omElement.getText();  // or omElement.toString();
>    _messageContext.getTransportOut().getSender().cleanup(_messageContext);
>    return omElement;
> The getText()/toString() has the effect that all binary data from the web service call
is loaded in the Axiom objects so they can be accessed in the client code which uses the MyStub.echoPdf()

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message