[
https://issues.apache.org/jira/browse/WSCOMMONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen reassigned WSCOMMONS-485:
-----------------------------------------
Assignee: Andreas Veithen
> The sequence of events produced by OMStAXWrapper for XOP:Include is
> inconsistent
> --------------------------------------------------------------------------------
>
> Key: WSCOMMONS-485
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-485
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Affects Versions: Axiom 1.2.8
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
>
> For an Axiom tree built by MTOMStAXSOAPModelBuilder (or
> XOPAwareStAXOMBuilder) the sequence of events produced by OMStAXWrapper (i.e.
> the reader returned by getXMLStreamReader and
> getXMLStreamReaderWithoutCaching) for an XOP:Include element in the
> underlying stream depends on the state of the tree and on whether caching is
> enabled or not:
> Scenario 1: The tree has already been built. In this case OMStAXWrapper
> produces a CHARACTER event on which the OMConstants.DATA_HANDLER property can
> be queried. This is true both for caching enabled and disabled.
> Scenario 2: The tree has not been built and caching is enabled. In this case
> OMStAXWrapper produces an invalid sequence of events: namely, there is a
> spurious END_DOCUMENT event. Except for this bug, in this case OMStAXWrapper
> behaves as described in scenario 1.
> Scenario 3: The tree has not been built and caching is disabled. In this case
> OMStAXWrapper delegates to the raw StAX stream and produces START_ELEMENT and
> END_ELEMENT events for the XOP:Include element, leaving it up to the client
> code to decode XOP.
> Conclusion:
> - When caching is disabled, the sequence of events depends on the state of
> the tree (built or not).
> - The sequence of events produced by getXMLStreamReader and
> getXMLStreamReaderWithoutCaching is not the same.
> Since aspects such as caching and the state of the tree should be transparent
> to the client code, Axiom should be fixed so that OMStAXWrapper produces the
> same sequence of events in all cases. The correct sequence is the one
> described in scenario 1, because it is Axiom's responsibility to decode XOP.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
