[jira] Commented: (WSCOMMONS-52) MTOM Attachments does not get build when SOAPEnvelope.build() method is called.

["Thilina Gunarathne (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/WSCOMMONS-52?page=comments#action_12419084 ] 

Thilina Gunarathne commented on WSCOMMONS-52:
---------------------------------------------

In the current implementation SOAPEnvelope.build()  calls the parser.next() from ONNodeImpl which causes the tree to build. But for MTOM attachments this will only create OMText place holders without reading the actual binary content.

IMO we need a delegating build() method which will delegate it to each and every child of that element, so that we can override build() from OMText to read whatever the binary when it is called.  IIRC this was the behaviour of build() some time back... Not sure whether this is removed due to performance reasons. 

We need to discuss this bit further If this is removed due to performance reasons..

> MTOM Attachments does not get build when SOAPEnvelope.build() method is called.
> -------------------------------------------------------------------------------
>
>          Key: WSCOMMONS-52
>          URL: http://issues.apache.org/jira/browse/WSCOMMONS-52
>      Project: WS-Commons
>         Type: Bug

>   Components: AXIOM
>     Reporter: Chamikara Jayalath

>
> It seems that even after the SOAPEnvelope.build () method is called the attachments are kept on the stream. This will cause errors if the sream get closed before the attachments are actually read. 
> One of the ideas behind MTOM is to hide the fact that the data is actually sent as attachments. So the user calling a SOAPEnvelope.build() method would natuarally expect the attachments also to be built.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org