If the message uses MTOM, then Axiom knows which part of it are binary
and the binary property of the OMText node is set automatically.
Calling setBinary explicitly is only required for plain XML containing
base64 encoded data, so that Axiom knows which parts of it need to be
decoded. I checked the Axiom code and this behavior is validated by a
couple of unit tests. Thus, if you get an OMText node with
binary=false, then the message was not MTOM or you did some
transformations that caused the attachment to be inlined as base64
data.
Andreas
On Wed, Oct 13, 2010 at 14:26, Anirban Majumdar
<anirban.majum...@altair.com> wrote:
> Hello Andreas,
>
> Going through the source of the axiom-impl-1.2.9 [OMTextImpl], I came across
> the following -
>
> /**
> * Receiving binary can happen as either MTOM attachments or as Base64
> Text In the case of
> * Base64 user has to explicitly specify that the content is binary,
> before calling
> * getDataHandler(), getInputStream()....
> */
> setBinary(Boolean value) {
> ...
> }
>
> Perhaps the API is designed to be used this way...?
>
> --------
> anirban
>
>
> -----Original Message-----
> From: Anirban Majumdar
> Sent: Wednesday, October 13, 2010 11:41 AM
> To: 'commons-dev@ws.apache.org'
> Subject: RE: Axis2/Axiom handling SOAP MTOM/non-MTOM attachments
>
> I'm using Axiom 1.2.9.
> Andreas - the reason I might need to do set the binary flag is perhaps
> because my Axiom based client is not for a particular web-service
> application. This client is pretty much acting as a 'proxy'. However, it's
> supposed to do a bit more than a proxy. It is supposed to transform all
> out-bound messages from web-services to a standard format. When it receives
> requests in the standard format, it again needs to transform them back to the
> particular web-service's format. For handling attachments, it adopts a
> mime-type agnostic approach, and treats all attachments as binary data.
>
> I'm assuming that since the Axiom client does not work w/ ADB generated
> bindings so it can't be sure how to treat the attachment data, and hence, I
> explicitly need to set the binary flag to 'true'. I'm working at the raw SOAP
> message level w/ Axiom. However, if you feel that Axiom should not need to be
> instructed about the binary flag, then I'm wrong and have no clue :]
>
> Let me know if there's any other information I can help you w/. Since the
> client is a generic implementation, I could send it across to you if you want
> to take a look.
>
> Thanks,
> --------
> anirban
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veit...@gmail.com]
> Sent: Wednesday, October 13, 2010 2:27 AM
> To: commons-dev@ws.apache.org
> Subject: Re: Axis2/Axiom handling SOAP MTOM/non-MTOM attachments
>
> If you need to explicitly set binary=true, then there is something
> wrong. What version of Axiom and Axis2 do you use?
>
> Andreas
>
> On Tue, Oct 12, 2010 at 14:52, Anirban Majumdar
> <anirban.majum...@altair.com> wrote:
>> Hello,
>>
>> I just figured that I need to invoke .setBinary(true) to have it working for
>> me. Strangely enough this information has not been relayed in most of the
>> tutorials describing how to write clients to handle attachments.
>>
>> Thanks for providing the initial direction!
>> --------
>> anirban
>>
>>
>> -----Original Message-----
>> From: Anirban Majumdar
>> Sent: Tuesday, October 12, 2010 3:02 PM
>> To: commons-dev@ws.apache.org
>> Subject: RE: Axis2/Axiom handling SOAP MTOM/non-MTOM attachments
>>
>> 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
>>>
>>>
>>>
>>>
>>
>
