[
https://issues.apache.org/jira/browse/WSCOMMONS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved WSCOMMONS-488.
---------------------------------------
Resolution: Fixed
Fix Version/s: Axiom 1.2.9
> The sequence of events produced by OMStAXWrapper with inlineMTOM=false is
> inconsistent
> --------------------------------------------------------------------------------------
>
> Key: WSCOMMONS-488
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-488
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Affects Versions: Axiom 1.2.8
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
> Priority: Minor
> Fix For: Axiom 1.2.9
>
>
> The inlineMTOM=false mode in OMStAXWrapper (introduced by WSCOMMONS-344) only
> works in a consistent way if the underlying StAX stream comes from an
> MTOM/XOP message, but not if the underlying stream uses the
> IS_DATA_HANDLERS_AWARE extension. Indeed:
> - If the OMStAXWrapper is generating events from the Axiom tree (because
> caching is enabled or the tree has already been built), then the change in
> WSCOMMONS-344 makes sure that an XOP:Include element is returned for
> optimized binary content.
> - On the other hand, if caching is disabled and the Axiom tree has not been
> built, OMStAXWrapper delegates to the underlying stream reader. If there is
> optimized binary content, it will be represented as a CHARACTERS event
> instead of an XOP:Include element (as in inlineMTOM=true mode).
> Since this issue only occurs if inlineMTOM=false (which is not the default)
> and the underlying stream uses the IS_DATA_HANDLERS_AWARE extension (which is
> generally only the case for a stream coming from another Axiom tree or
> generated by a databinding framework), this issue is less serious than
> WSCOMMONS-485.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
