You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2010/05/19 22:27:53 UTC
[jira] Created: (WSCOMMONS-540) CustomBuilder interface is not well
defined for optimized binary data
CustomBuilder interface is not well defined for optimized binary data
---------------------------------------------------------------------
Key: WSCOMMONS-540
URL: https://issues.apache.org/jira/browse/WSCOMMONS-540
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Reporter: Andreas Veithen
Assignee: Andreas Veithen
Fix For: Axiom 1.2.9
The CustomBuilder contract doesn't specify very well how the implementation is supposed to handle documents with optimized binary data (either from an XOP encoded document or exposed by the OMConstants.DATA_HANDLER / DataHandlerReader extension).
Situation in Axiom 1.2.8: In all cases, the XMLStreamReader passed to the CustomBuilder is the original reader passed to StAXOMBuilder. This means that if the document/message is XOP, the XMLStreamReader passed to CustomBuilder represents an XOP encoded stream. However, in other cases the XMLStreamReader may expose optimized binary data using the OMConstants.DATA_HANDLER property. Therefore the CustomBuilder needs to be able to handle two different cases.
Current situation (since r795595): If the original document/message is XOP, then the XMLStreamReader passed to CustomBuilder will now be a XOPDecodingStreamReader exposing the optimized binary data through a DataHandlerReader. Thus, in all cases, the XMLStreamReader passed to CustomBuilder represents plain XML with optional support for DataHandlerReader. That is consistent and suitable for CustomBuilders that require the binary data as base64 encoded character data or that support the Axiom specific DataHandlerReader extension. However, it makes things more difficult for CustomBuilders that require an XOP encoded stream. This is often required when interacting with third-party libraries to make sure that binary data is handled efficiently. An example of this is JAXB2 (see also WSCOMMONS-344).
Suggested fix: Complete the Javadoc of the CustomBuilder to specify how StAXOMBuilder delivers optimized binary data and how the implementation can get an XOP encoded stream. For the last part, it is necessary to cover the following cases:
1. If the XMLStreamReader passed to StAXOMBuilder was created by parsing a plain XML document, then no special action is required.
2. If the original document is XOP encoded, then the XOPDecodingStreamReader needs to be unwrapped to get access to the original stream.
3. If the XMLStreamReader passed to StAXOMBuilder implements the DataHandlerReader extension, then it needs to be wrapped with an XOPEncodingStreamReader.
Obviously, there should be a utility method implementing this algorithm.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WSCOMMONS-540) CustomBuilder interface is not
well defined for optimized binary data
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen resolved WSCOMMONS-540.
---------------------------------------
Resolution: Fixed
Implemented as described above.
> CustomBuilder interface is not well defined for optimized binary data
> ---------------------------------------------------------------------
>
> Key: WSCOMMONS-540
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-540
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
> Fix For: Axiom 1.2.9
>
>
> The CustomBuilder contract doesn't specify very well how the implementation is supposed to handle documents with optimized binary data (either from an XOP encoded document or exposed by the OMConstants.DATA_HANDLER / DataHandlerReader extension).
> Situation in Axiom 1.2.8: In all cases, the XMLStreamReader passed to the CustomBuilder is the original reader passed to StAXOMBuilder. This means that if the document/message is XOP, the XMLStreamReader passed to CustomBuilder represents an XOP encoded stream. However, in other cases the XMLStreamReader may expose optimized binary data using the OMConstants.DATA_HANDLER property. Therefore the CustomBuilder needs to be able to handle two different cases.
> Current situation (since r795595): If the original document/message is XOP, then the XMLStreamReader passed to CustomBuilder will now be a XOPDecodingStreamReader exposing the optimized binary data through a DataHandlerReader. Thus, in all cases, the XMLStreamReader passed to CustomBuilder represents plain XML with optional support for DataHandlerReader. That is consistent and suitable for CustomBuilders that require the binary data as base64 encoded character data or that support the Axiom specific DataHandlerReader extension. However, it makes things more difficult for CustomBuilders that require an XOP encoded stream. This is often required when interacting with third-party libraries to make sure that binary data is handled efficiently. An example of this is JAXB2 (see also WSCOMMONS-344).
> Suggested fix: Complete the Javadoc of the CustomBuilder to specify how StAXOMBuilder delivers optimized binary data and how the implementation can get an XOP encoded stream. For the last part, it is necessary to cover the following cases:
> 1. If the XMLStreamReader passed to StAXOMBuilder was created by parsing a plain XML document, then no special action is required.
> 2. If the original document is XOP encoded, then the XOPDecodingStreamReader needs to be unwrapped to get access to the original stream.
> 3. If the XMLStreamReader passed to StAXOMBuilder implements the DataHandlerReader extension, then it needs to be wrapped with an XOPEncodingStreamReader.
> Obviously, there should be a utility method implementing this algorithm.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.