Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
None
Description
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.
Attachments
Issue Links
- is related to
-
-
- Closed
-
- relates to
-
-
- Resolved
-