Hello Andreas,
Thanks for the reply. The part about MTOM/XOP pre-processing makes sense.
Considering your example -
<ns:document><xop:Include href="cid:xxxx@yyyy"/></ns:document>
I followed your suggestion and looked for a child node under the OMElement
represent ns:document. And there I found a OMTextImpl instance. I believe I
made a mistake in the method I was invoking on the OMElement. I was simply
doing getFirstElement, whereas I should've done getFirstOMChild.
Having done the above, now I'm witnessing another problem in constructing a
file from the binary data -
What I do is -
OMText tNode = (OMText) elem.getFirstOMChild(); #1
System.out.println(tNode.getContentID()); #2
DataHandler dh = tNode.getDataHandler(); #3
At #2 I get the content ID fine. However, at #3, I'm getting a
NullPointerException. Using TCPMon I can see that the attachment is coming
through fine with a content-type "application/octet-stream". I hope I'm not
looking over some detail this time too :/
Thanks,
--------
anirban
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veit...@gmail.com]
Sent: Monday, October 11, 2010 11:33 PM
To: commons-dev@ws.apache.org
Subject: Re: Axis2/Axiom handling SOAP MTOM/non-MTOM attachments
In Axiom, MTOM/XOP processing happens before building the nodes.
Therefore you will never see OMElement instances for xop:Include
elements (there were some cases in Axiom 1.2.8 where one could still
see xop:Include elements in XMLStreamReaders returned by Axiom, but in
1.2.9 XOP is now always decoded consistently in all cases). Instead,
Axiom will generate an OMText instance from which a DataHandler with
the content can be retrieved. If the document or part of it is
serialized, then the optimized content will indeed be base64 encoded
and inlined, unless a properly configured OMOutputFormat is passed to
the serialize method. You can't cast an OMElement to an OMText node
since they represent two different node types. Probably you are simply
looking at the wrong node.
To make this clearer, let's consider the following input document fragment:
<ns:document><xop:Include href="cid:xxxx@yyyy"/></ns:document>
You will get an OMElement describing ns:document, with a single OMText
child that gives you the DataHandler.
Hope this helps.
Andreas
On Mon, Oct 11, 2010 at 16:28, Anirban Majumdar
<anirban.majum...@altair.com> wrote:
> After looking around and trying different suggested solutions, I'm
> writing this. The 2 most common solutions suggested to extract binary
> data from a MTOM/non-MTOM SOAP message are:
>
> 1. Retrieve the OMText node, and use the dataHandler instance
> present within it
> 2. Find the OMElement node which contains the 'href' attribute. Get
> the 'cid:xxxxx' value, and use the 'xxxxx' part to retrieve the
> attachment from the attachment map present in the message context
> instance.
>
> The problem I'm facing is that my client application indicates that the
> SOAP response message is MTOM [I determined this using the isDoingMTOM()
> method of the message context instance]. However, there are no OMElement
> nodes which contain the 'href' attribute. On printing the SOAP envelope,
> I found that the binary data is present inline within the body. So I
> tried the OMText node approach to get the data, but whenever I try to
> cast the OMElement to the corresponding OMText node, I keep getting a
> classCastException.
>
> Can someone point out what I'm missing out on?
>
>
>
>
>
> --------
>
> anirban
>
>
>
>
