ws-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Commented: (WSCOMMONS-485) The sequence of events produced by OMStAXWrapper for XOP:Include is inconsistent
Date Mon, 06 Jul 2009 21:21:14 GMT


Andreas Veithen commented on WSCOMMONS-485:

Proposed solution:

Currently, XOP:Include is decoded by MTOMStAXSOAPModelBuilder or XOPAwareStAXOMBuilder (the
code is duplicated in both classes). Instead of this, create an XMLStreamReader wrapper that
does the XOP decoding. It would use the IS_DATA_HANDLERS_AWARE extension so that the builder
can retrieve the DataHandler objects. This wrapper would sit between the underlying parser
and StAXOMBuilder (which already supports the IS_DATA_HANDLERS_AWARE extension). When caching
is disabled (and the tree has not been built), OMStAXWrapper would then delegate to this wrapper
instead of the underlying parser. This would solve the issue in scenario 3. Probably the issue
in scenario 2 would also go away. In addition, this approach makes sure that there is one
and only one piece of code responsible for XOP decoding.

There are however two obstacles with this approach:
- MTOMStAXSOAPModelBuilder and XOPAwareStAXOMBuilder support deferred loading of the DataHandler
and this feature must be preserved. On the other hand, the IS_DATA_HANDLERS_AWARE extension
doesn't allow deferred loading of the DataHandler. => need to implement WSCOMMONS-487 first
- The fact that OMStAXWrapper would get an XOP decoded stream from StAXOMBuilder would aggravate
the issue described in WSCOMMONS-488. => needs to be fixed first

> The sequence of events produced by OMStAXWrapper for XOP:Include is inconsistent
> --------------------------------------------------------------------------------
>                 Key: WSCOMMONS-485
>                 URL:
>             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.

View raw message