You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Wolfram Kaiser (JIRA)" <ji...@apache.org> on 2006/06/02 11:48:32 UTC
[jira] Created: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Returning a MTOM message causes IOException (closed stream)
-----------------------------------------------------------
Key: AXIS2-795
URL: http://issues.apache.org/jira/browse/AXIS2-795
Project: Apache Axis 2.0 (Axis2)
Type: Bug
Components: databinding
Versions: 1.0
Environment: JDK 1.4.2_06
Reporter: Wolfram Kaiser
When accessing an attachment sent via MTOM on the client side I get the following exception:
org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
java.io.IOException: Attempted read on closed stream.
at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
...
_messageContext.getTransportOut().getSender().cleanup(_messageContext);
return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
...
org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-795?page=comments#action_12438988 ]
Davanum Srinivas commented on AXIS2-795:
----------------------------------------
Folks,
I am willing to upgrade this bug to blocker if i get a sample for us to recreate the problem. Can you please help?
thanks,
dims
> Returning a MTOM message causes IOException (closed stream)
> -----------------------------------------------------------
>
> Key: AXIS2-795
> URL: http://issues.apache.org/jira/browse/AXIS2-795
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: databinding
> Affects Versions: 1.0
> Environment: JDK 1.4.2_06
> Reporter: Wolfram Kaiser
> Assigned To: Thilina Gunarathne
>
> When accessing an attachment sent via MTOM on the client side I get the following exception:
> org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
> java.io.IOException: Attempted read on closed stream.
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
> at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
> at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
> at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
> at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
> The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
> public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Posted by "Alex Rodriguez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524122 ]
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: https://issues.apache.org/jira/browse/AXIS2-795
> 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:
> org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
> java.io.IOException: Attempted read on closed stream.
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
> at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
> at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
> at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
> at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
> The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
> public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Posted by "Thilina Gunarathne (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-795?page=all ]
Thilina Gunarathne resolved AXIS2-795.
--------------------------------------
Resolution: Incomplete
Need a sample to test....
> Returning a MTOM message causes IOException (closed stream)
> -----------------------------------------------------------
>
> Key: AXIS2-795
> URL: http://issues.apache.org/jira/browse/AXIS2-795
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: databinding
> Affects Versions: 1.0
> Environment: JDK 1.4.2_06
> Reporter: Wolfram Kaiser
> Assigned To: Thilina Gunarathne
>
> When accessing an attachment sent via MTOM on the client side I get the following exception:
> org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
> java.io.IOException: Attempted read on closed stream.
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
> at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
> at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
> at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
> at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
> The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
> public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-795?page=all ]
Deepal Jayasinghe reassigned AXIS2-795:
---------------------------------------
Assign To: Ajith Harshana Ranabahu
> Returning a MTOM message causes IOException (closed stream)
> -----------------------------------------------------------
>
> Key: AXIS2-795
> URL: http://issues.apache.org/jira/browse/AXIS2-795
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: databinding
> Versions: 1.0
> Environment: JDK 1.4.2_06
> Reporter: Wolfram Kaiser
> Assignee: Ajith Harshana Ranabahu
>
> When accessing an attachment sent via MTOM on the client side I get the following exception:
> org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
> java.io.IOException: Attempted read on closed stream.
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
> at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
> at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
> at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
> at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
> The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
> public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Posted by "James Scott (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-795?page=comments#action_12430145 ]
James Scott commented on AXIS2-795:
-----------------------------------
Had a very similar issue with a non-data-binding client (generated by wsdl2java) using a very simple service (return type was a single element of type String). Once the response grew long enough that the server would send it in two or more chunks, the client would throw the "Attempted read on closed stream" exception. The debug output made it look as though the client never pulled the second chunk.
Generating an ADB-style client from the same WSDL did not produce this error.
> Returning a MTOM message causes IOException (closed stream)
> -----------------------------------------------------------
>
> Key: AXIS2-795
> URL: http://issues.apache.org/jira/browse/AXIS2-795
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: databinding
> Affects Versions: 1.0
> Environment: JDK 1.4.2_06
> Reporter: Wolfram Kaiser
> Assigned To: Ajith Harshana Ranabahu
>
> When accessing an attachment sent via MTOM on the client side I get the following exception:
> org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
> java.io.IOException: Attempted read on closed stream.
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
> at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
> at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
> at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
> at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
> The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
> public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-795) Returning a MTOM message causes
IOException (closed stream)
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-795?page=all ]
Davanum Srinivas reassigned AXIS2-795:
--------------------------------------
Assignee: Thilina Gunarathne (was: Ajith Harshana Ranabahu)
> Returning a MTOM message causes IOException (closed stream)
> -----------------------------------------------------------
>
> Key: AXIS2-795
> URL: http://issues.apache.org/jira/browse/AXIS2-795
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: databinding
> Affects Versions: 1.0
> Environment: JDK 1.4.2_06
> Reporter: Wolfram Kaiser
> Assigned To: Thilina Gunarathne
>
> When accessing an attachment sent via MTOM on the client side I get the following exception:
> org.apache.axiom.om.OMException: javax.mail.MessagingException: Error in input stream; nested exception is:
> java.io.IOException: Attempted read on closed stream.
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:462)
> at org.apache.axiom.attachments.Attachments.getNextPart(Attachments.java:359)
> at org.apache.axiom.attachments.Attachments.getPart(Attachments.java:324)
> at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:274)
> at org.apache.axiom.om.impl.mtom.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:151)
> at org.apache.axiom.om.impl.llom.OMTextImpl.getDataHandler(OMTextImpl.java:341)
> The client stub was generated using the default / no data binding (-> direct Axiom access). I believe the error is in the generated stub:
> public org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> _messageContext.getTransportOut().getSender().cleanup(_messageContext);
> return (org.apache.axiom.om.OMElement) 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 org.apache.axiom.om.OMElement echoPdf(org.apache.axiom.om.OMElement param48) throws java.rmi.RemoteException {
> ...
> org.apache.axiom.om.OMElement omElement = (org.apache.axiom.om.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() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org