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