[jira] Commented: (WSCOMMONS-344) OMStaXWrapper Does Not Support Optimized OMText as an XOP:Include

["Rich Scheuerle (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WSCOMMONS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596386#action_12596386 ] 

Rich Scheuerle commented on WSCOMMONS-344:
------------------------------------------

Committed the Axiom portion of the change.  Revision=655845
Working on the Axis2/JAXWS/JAXB enablement

> OMStaXWrapper Does Not Support Optimized OMText as 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.