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 "Christoph Ludwig (JIRA)" <ji...@apache.org> on 2008/02/01 14:43:09 UTC
[jira] Created: (AXIS2-3488) WstxIOException on long base64Binary
elements
WstxIOException on long base64Binary elements
---------------------------------------------
Key: AXIS2-3488
URL: https://issues.apache.org/jira/browse/AXIS2-3488
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: om
Affects Versions: 1.3
Environment: JDK 1.5
Reporter: Christoph Ludwig
Attachments: Axis2_LargeBase64.zip
We have a client that does not use a databinding but operates on AXIOM OMElements. The WSDL specifies that part of the response is Base64Binary data. However, when we try to access this data then we get WstxIOExceptions ("Attempted read on closed stream") as soon as the data's length exceeds some threshold.
Martin Gainty suggested on axis-user@ws.apache.org this may be related to issue #3311 <URL:https://issues.apache.org/jira/browse/AXIS2-3311>. I am not convinced, though, since our problems manifests itself no matter if send requests for the first time or if we re-send them. It is only a matter of the data's length.
I am going to attach a test case that demonstrates
* the excpetion is thrown as soon as the string that is transported base64 encoded is longer than 2850 characters.
* the ADB binding manages to avoid this issue.
The service archive Axis2_LargeBase64/LargeBase64.aar packs test.axis2.lb64.service. The junit testcase in test.axis2.lb64.client.om.junit demonstrates the issue with the client that operates directly on OMElements. Similarly, test.axis2.lb64.client.adb.junit exhibits that the ADB binding somehow avoids this issue. All client stubs and the service skeleton were generated with the Axis2 wsdl2java tool through the Eclipse Axis2 Code Generator Wizard.
We'd prefer to avoid ADB (or other bindings) for this particular client and would therefore appreciate any fix or even workaround.
--
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] Assigned: (AXIS2-3488) WstxIOException on long base64Binary
elements
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-3488:
----------------------------------------
Assignee: Deepal Jayasinghe
> WstxIOException on long base64Binary elements
> ---------------------------------------------
>
> Key: AXIS2-3488
> URL: https://issues.apache.org/jira/browse/AXIS2-3488
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: om
> Affects Versions: 1.3
> Environment: JDK 1.5
> Reporter: Christoph Ludwig
> Assignee: Deepal Jayasinghe
> Attachments: Axis2_LargeBase64.zip
>
>
> We have a client that does not use a databinding but operates on AXIOM OMElements. The WSDL specifies that part of the response is Base64Binary data. However, when we try to access this data then we get WstxIOExceptions ("Attempted read on closed stream") as soon as the data's length exceeds some threshold.
> Martin Gainty suggested on axis-user@ws.apache.org this may be related to issue #3311 <URL:https://issues.apache.org/jira/browse/AXIS2-3311>. I am not convinced, though, since our problems manifests itself no matter if send requests for the first time or if we re-send them. It is only a matter of the data's length.
> I am going to attach a test case that demonstrates
> * the excpetion is thrown as soon as the string that is transported base64 encoded is longer than 2850 characters.
> * the ADB binding manages to avoid this issue.
> The service archive Axis2_LargeBase64/LargeBase64.aar packs test.axis2.lb64.service. The junit testcase in test.axis2.lb64.client.om.junit demonstrates the issue with the client that operates directly on OMElements. Similarly, test.axis2.lb64.client.adb.junit exhibits that the ADB binding somehow avoids this issue. All client stubs and the service skeleton were generated with the Axis2 wsdl2java tool through the Eclipse Axis2 Code Generator Wizard.
> We'd prefer to avoid ADB (or other bindings) for this particular client and would therefore appreciate any fix or even workaround.
--
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] Issue Comment Edited: (AXIS2-3488) WstxIOException on long
base64Binary elements
Posted by "Christoph Ludwig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564759#action_12564759 ]
cludwig edited comment on AXIS2-3488 at 2/1/08 5:43 AM:
-----------------------------------------------------------------
test case attached
was (Author: cludwig):
test case
> WstxIOException on long base64Binary elements
> ---------------------------------------------
>
> Key: AXIS2-3488
> URL: https://issues.apache.org/jira/browse/AXIS2-3488
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: om
> Affects Versions: 1.3
> Environment: JDK 1.5
> Reporter: Christoph Ludwig
> Attachments: Axis2_LargeBase64.zip
>
>
> We have a client that does not use a databinding but operates on AXIOM OMElements. The WSDL specifies that part of the response is Base64Binary data. However, when we try to access this data then we get WstxIOExceptions ("Attempted read on closed stream") as soon as the data's length exceeds some threshold.
> Martin Gainty suggested on axis-user@ws.apache.org this may be related to issue #3311 <URL:https://issues.apache.org/jira/browse/AXIS2-3311>. I am not convinced, though, since our problems manifests itself no matter if send requests for the first time or if we re-send them. It is only a matter of the data's length.
> I am going to attach a test case that demonstrates
> * the excpetion is thrown as soon as the string that is transported base64 encoded is longer than 2850 characters.
> * the ADB binding manages to avoid this issue.
> The service archive Axis2_LargeBase64/LargeBase64.aar packs test.axis2.lb64.service. The junit testcase in test.axis2.lb64.client.om.junit demonstrates the issue with the client that operates directly on OMElements. Similarly, test.axis2.lb64.client.adb.junit exhibits that the ADB binding somehow avoids this issue. All client stubs and the service skeleton were generated with the Axis2 wsdl2java tool through the Eclipse Axis2 Code Generator Wizard.
> We'd prefer to avoid ADB (or other bindings) for this particular client and would therefore appreciate any fix or even workaround.
--
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] Updated: (AXIS2-3488) WstxIOException on long base64Binary
elements
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated AXIS2-3488:
------------------------------------
Fix Version/s: (was: 1.4)
Looks like we may not be able to look at this one...postponing.
thanks,
dims
> WstxIOException on long base64Binary elements
> ---------------------------------------------
>
> Key: AXIS2-3488
> URL: https://issues.apache.org/jira/browse/AXIS2-3488
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: om
> Affects Versions: 1.3
> Environment: JDK 1.5
> Reporter: Christoph Ludwig
> Assignee: Rich Scheuerle
> Attachments: Axis2_LargeBase64.zip
>
>
> We have a client that does not use a databinding but operates on AXIOM OMElements. The WSDL specifies that part of the response is Base64Binary data. However, when we try to access this data then we get WstxIOExceptions ("Attempted read on closed stream") as soon as the data's length exceeds some threshold.
> Martin Gainty suggested on axis-user@ws.apache.org this may be related to issue #3311 <URL:https://issues.apache.org/jira/browse/AXIS2-3311>. I am not convinced, though, since our problems manifests itself no matter if send requests for the first time or if we re-send them. It is only a matter of the data's length.
> I am going to attach a test case that demonstrates
> * the excpetion is thrown as soon as the string that is transported base64 encoded is longer than 2850 characters.
> * the ADB binding manages to avoid this issue.
> The service archive Axis2_LargeBase64/LargeBase64.aar packs test.axis2.lb64.service. The junit testcase in test.axis2.lb64.client.om.junit demonstrates the issue with the client that operates directly on OMElements. Similarly, test.axis2.lb64.client.adb.junit exhibits that the ADB binding somehow avoids this issue. All client stubs and the service skeleton were generated with the Axis2 wsdl2java tool through the Eclipse Axis2 Code Generator Wizard.
> We'd prefer to avoid ADB (or other bindings) for this particular client and would therefore appreciate any fix or even workaround.
--
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] Updated: (AXIS2-3488) WstxIOException on long base64Binary
elements
Posted by "Christoph Ludwig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christoph Ludwig updated AXIS2-3488:
------------------------------------
Attachment: Axis2_LargeBase64.zip
test case
> WstxIOException on long base64Binary elements
> ---------------------------------------------
>
> Key: AXIS2-3488
> URL: https://issues.apache.org/jira/browse/AXIS2-3488
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: om
> Affects Versions: 1.3
> Environment: JDK 1.5
> Reporter: Christoph Ludwig
> Attachments: Axis2_LargeBase64.zip
>
>
> We have a client that does not use a databinding but operates on AXIOM OMElements. The WSDL specifies that part of the response is Base64Binary data. However, when we try to access this data then we get WstxIOExceptions ("Attempted read on closed stream") as soon as the data's length exceeds some threshold.
> Martin Gainty suggested on axis-user@ws.apache.org this may be related to issue #3311 <URL:https://issues.apache.org/jira/browse/AXIS2-3311>. I am not convinced, though, since our problems manifests itself no matter if send requests for the first time or if we re-send them. It is only a matter of the data's length.
> I am going to attach a test case that demonstrates
> * the excpetion is thrown as soon as the string that is transported base64 encoded is longer than 2850 characters.
> * the ADB binding manages to avoid this issue.
> The service archive Axis2_LargeBase64/LargeBase64.aar packs test.axis2.lb64.service. The junit testcase in test.axis2.lb64.client.om.junit demonstrates the issue with the client that operates directly on OMElements. Similarly, test.axis2.lb64.client.adb.junit exhibits that the ADB binding somehow avoids this issue. All client stubs and the service skeleton were generated with the Axis2 wsdl2java tool through the Eclipse Axis2 Code Generator Wizard.
> We'd prefer to avoid ADB (or other bindings) for this particular client and would therefore appreciate any fix or even workaround.
--
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] Updated: (AXIS2-3488) WstxIOException on long base64Binary
elements
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated AXIS2-3488:
------------------------------------
Fix Version/s: 1.4
Assignee: Rich Scheuerle (was: Deepal Jayasinghe)
Rich,
can you please take a look at this?
> WstxIOException on long base64Binary elements
> ---------------------------------------------
>
> Key: AXIS2-3488
> URL: https://issues.apache.org/jira/browse/AXIS2-3488
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: om
> Affects Versions: 1.3
> Environment: JDK 1.5
> Reporter: Christoph Ludwig
> Assignee: Rich Scheuerle
> Fix For: 1.4
>
> Attachments: Axis2_LargeBase64.zip
>
>
> We have a client that does not use a databinding but operates on AXIOM OMElements. The WSDL specifies that part of the response is Base64Binary data. However, when we try to access this data then we get WstxIOExceptions ("Attempted read on closed stream") as soon as the data's length exceeds some threshold.
> Martin Gainty suggested on axis-user@ws.apache.org this may be related to issue #3311 <URL:https://issues.apache.org/jira/browse/AXIS2-3311>. I am not convinced, though, since our problems manifests itself no matter if send requests for the first time or if we re-send them. It is only a matter of the data's length.
> I am going to attach a test case that demonstrates
> * the excpetion is thrown as soon as the string that is transported base64 encoded is longer than 2850 characters.
> * the ADB binding manages to avoid this issue.
> The service archive Axis2_LargeBase64/LargeBase64.aar packs test.axis2.lb64.service. The junit testcase in test.axis2.lb64.client.om.junit demonstrates the issue with the client that operates directly on OMElements. Similarly, test.axis2.lb64.client.adb.junit exhibits that the ADB binding somehow avoids this issue. All client stubs and the service skeleton were generated with the Axis2 wsdl2java tool through the Eclipse Axis2 Code Generator Wizard.
> We'd prefer to avoid ADB (or other bindings) for this particular client and would therefore appreciate any fix or even workaround.
--
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