Got it :] It makes perfect sense now - and thank you so much Andreas!
-------- anirban -----Original Message----- From: Andreas Veithen [mailto:andreas.veit...@gmail.com] Sent: Saturday, October 16, 2010 2:11 PM To: commons-dev@ws.apache.org Subject: Re: Axis2/Axiom handling SOAP MTOM/non-MTOM attachments On Thu, Oct 14, 2010 at 08:05, Anirban Majumdar <anirban.majum...@altair.com> wrote: > Makes sense - though I don't really do any transformation at the client side, > so it might be to do w/ the remote web-service. > This leads me to ask - in case of a plain XML containing a non-binary > attachment, will it cause an exception if the 'binary' flag is turned on > before extracting the attachment content? The question doesn't make sense. If the message is plain XML and not MTOM, then there is no such thing as an "attachment". > -------- > anirban > > -----Original Message----- > From: Andreas Veithen [mailto:andreas.veit...@gmail.com] > Sent: Thursday, October 14, 2010 1:10 AM > To: commons-dev@ws.apache.org > Subject: Re: Axis2/Axiom handling SOAP MTOM/non-MTOM attachments > > 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 >>>> >>>> >>>> >>>> >>> >> >
