OMStaXWrapper Does Not Support Optimized OMTextas an XOP:Include
----------------------------------------------------------------
Key: WSCOMMONS-344
URL: https://issues.apache.org/jira/browse/WSCOMMONS-344
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle
Scenario:
A fully built OM tree.
One of the OMText nodes is an Optimized MTOM Attachment (isOptimized==true).
The getXMLStreamReader() method is called on the root, which returns an
OMStAXWrapper (assuming llom).
There are actually 4 different ways that the XMLStreamReader user can access
the data of the optimized MTOM attachment.
------------------------------------------
METHOD A: Inline the DataHandler as Text (CURRENT DEFAULT).
The OMStAXWrapper generates a TEXT event. The consumer then calls
getTextCharacters() which returns the text representation of the entire
DataHandler contents.
Pros: This mechanism is adequate for all XMLStreamReaders users.
Cons: Can lead to OutOfMemory exceptions if the DataHandler content is very
large.
-------------------------------------------
METHOD B: Access the DataHandler as a Proprietary Property (CURRENTLY
IMPLEMENTED)
The OMStAXWrapper generates a TEXT event. The consumer can use a special
proprietary property "Axiom.DataHandler" to get the DataHandler from the OMText.
Pros: Avoids the large string.
Cons: This is a proprietary call, and consumers like JAXB won't use this
property.
--------------------------------------------
METHOD C: Generate a series of TEXT events (NOT IMPLEMENTED)
The OMStaXWrapper could generate a series of smaller TEXT events. The
OMStAXWrapper is allowed to do this unless the "javax.xml.stream.isCoalescing"
on the XMLInputFactory is set to true.
Pros: This would be supported by all consumers. It would also reduce "out of
memory" situations because the DataHandler contents are split into many smaller
events.
Cons: Still inlining the DataHandler contents.
---------------------------------------------
METHOD D: Generate an XOP:Include element (PROPOSAL FOR THIS JIRA)
The OMStaXWrapper could generate an XOP:Include element. A MTOM aware consumer
(like a JAXB AttachmentUnmarshaller) can then use the CID to get the attachment.
This would not be the default behavior, it would be triggered by an attribute
on the OMStAXWrapper
Pros: Allows access to the DataHandler using the XOP:Include standard.
Cons: Needs to be triggered by an option, since not all XMLStreamReaders
understand XOP:Include.
===================================
I am working on the changes to OMStAXWrapper and a representative test.
ProposedDesign Summary:
-----------------------------------------
When the OMStAXWrapper visits an optimized OMText node, it will create a
temporary (detached) xop:include OMElement. This temporary element will be used
for the event issues. The OMStAXWrapper already supports a
getDataHandler(blobCID).
Here is the JAXB Unmarshalling Scenario With the Current Code
-------------------------------------------------------------------------------------------
The XMLStreamReader (OMStAXWrapper) generates a TEXT event for the optimized
OMText node (assume 400M)
The (sun or other) JAXB implementation calls
XMLStreamReader.getTextCharacters().
The XMLStreamReader (OMStAXWrapper) tries to build a very large text string and
dies with an OutOfMemory exception.
Here is the JAXB Unmarshalling Scenario After the Proposed Changes.
-----------------------------------------------------------------------------------
The XMLStreamReader (OMStAXWrapper) generates an XOP:Include event
The (sun or other) JAXB implementation obtains the blobcid using the
XMLStreamReader.getAttributeValue(...) method.
The JAXB implementation calls a plugged in JAXBAttachmentUnmarshaller to get
the DataHandler associated with the attachment.
The JAXBAttachmentUnmarshaller implementation (supplied by Axis2 JAXWS) is OM
Aware. It calls the getDataHandler(blobCID) method to get the DataHandler.
The DataHandler is returned to the JAXB implementation.
processing continues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
