[
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.
