[jira] Commented: (WSCOMMONS-518) Some consumers of Axiom need direct access to the orignal parser/XMLStreamReader

["Andreas Veithen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WSCOMMONS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876381#action_12876381 ] 

Andreas Veithen commented on WSCOMMONS-518:
-------------------------------------------

Some comments about the changes that have been done so far for this issue:

Unwrapping a wrapper and accessing the parent object is in general not a safe operation because it will invalidate the state of the wrapper (which may still be used later). Therefore I would like to limit this possibility to only those wrappers for which it is a safe operation. Therefore I propose to make the XMLStreamReaderWrapper#getParent() method protected and remove the XMLStreamReaderContainer interface from XMLStreamReaderWrapper. The interface would only be implemented by a subset of the wrappers (those for which unwrapping is a safe operation). This would include all wrappers used by the StAX dialect implementations, but not XOPDecodingStreamReader/XOPEncodingStreamReader (note that SafeXMLStreamReader no longer exists; see r947371).

WSCOMMONS-540 introduces a new API specifically to unwrap an XOPDecodingStreamReader. More precisely, this API (XOPUtils#getXOPEncodedStream) takes an arbitrary XMLStreamReader as input and returns an XOP encoded stream as well as an object to access the referenced MIME parts (Unwrapping an XOPDecodingStreamReader is one of 4 possible cases). Using a separate API here solves two issues:

1. XOPDecodingStreamReader will only be unwrapped when requested explicitly. This makes sure that the code knows what it is doing and doesn't accidentally unwrap an XOPDecodingStreamReader (which changes the sequence of events).
2. It provides a well defined way to access the MIME parts. (Note that the way to access the attachments is different for each of the 4 cases considered in XOPUtils#getXOPEncodedStream)

There is a test case that demonstrates how this is used to integrate with JAXB2 (see the org.apache.axiom.om.impl.builder package in axiom-integration). The JAXBAttachmentMarshaller implementation in Axis2 would have to be modified to use the same approach.

As for XOPEncodingStreamReader, currently I don't see any use case where one would want to unwrap it. The reason is that it is only added if explicitly requested. In particular, I believe that this case never occurs in the JAX-WS code in Axis2.

To summarize:
* I believe that after the proposed change all the cases relevant for JAX-WS are still covered (provided that the code is changed to use XOPUtils#getXOPEncodedStream in addition to XMLStreamReaderUtils#getOriginalXMLStreamReader).
* The API would be much safer, because it prevents people from messing around with Axiom internals and avoids situations where a wrapper gets unwrapped accidentally.

> Some consumers of Axiom need direct access to the orignal parser/XMLStreamReader
> --------------------------------------------------------------------------------
>
>                 Key: WSCOMMONS-518
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-518
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: AXIOM
>            Reporter: Rich Scheuerle
>            Assignee: Andreas Veithen
>             Fix For: Axiom 1.2.9
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> Background:
> The dialect, "safe reader" and other improvements to Axiom allow the Axiom builders and other Axiom specific code to accommodate differences between different vendor XMLStreamReader.
> The Axiom implementation has been changed to add wrappers and delegates around the original, system XMLStreamReader.
> Problem:
> I agree with these improvements, but there is currently no way for a consumer of Axiom to access the original XMLStreamReader.  A particular consumer may need to access the original XMLStreamReader due its dependency on a particular vendor implementation.
> Proposal/Solution:
> Two new methods are added to the XMStreamReaderUtils class:
>    /**
>      * getOriginalXMLStreamReader
>      * Searches the wrapper and delegate classes to find the original XMLStreamReader
>      * This method should only be used when a consumer of Axiom really needs to 
>      * access the original stream reader.
>      * @param parser XMLStreamReader used by Axiom
>      * @return original parser 
>      */
>     public static XMLStreamReader getOriginalXMLStreamReader(XMLStreamReader parser) ...
>    /**
>      * Searches the wrapper and delegate classes to find an XMLStreamReader
>      * that implements the OMAttachmentAccessor
>      * @param parser
>      * @return XMLStreamREader that implements OMAttachmentAccessor or null
>      */
>     public static XMLStreamReader getOMAttachmentAccessorXMLStreamReader(XMLStreamReader parser) ...
> To facilitate these changes, a new interface is proposed: XMLStreamReaderContainer.
> **
>  * Marker interface for Axiom XMLStreamReader classes that
>  * wrap or delegate to another (parent) XMLStreamReader.
>  * 
>  * The marker interface is necessary so that consumers 
>  * can access the original parser.
>  * @see XMLStreamReaderUtils
>  * 
>  * Note that the only the getParent() method is applicable.
>  * Please do not add a setParent() method since that would
>  * violate the immutable characteristic of the XMLStreamReaderWrapper
>  */
> public interface XMLStreamReaderContainer {
>     XMLStreamReader getParent();
> }
> Also:
> The ability to access the original XMLStreamReader and the OMAttachmentAccessor XMLStreamReader is necessary for the Axis2 JAX-WS JAXB Unmarshaling code.
> Once these two methods are added to Axiom, I will be using a different JIRA for the Axis2 change.
> Current State:
> Still doing my testing.

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