Hi Dan, Yes, that makes sense, agree. Utility method is more elegant solution with less overhead.
For example we can extend org.apache.cxf.attachment.AttachmentUtil with proposed addXOPElement() utility methods. @Alekhya: does it make sense for you? Patch is welcome :) Regards, Andrei. > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Mittwoch, 26. Februar 2014 17:30 > To: [email protected] > Cc: Gumudavelli, Alekhya > Subject: Re: Query on CXF dispatch client with MTOM > > > On Feb 26, 2014, at 8:34 AM, Andrei Shakirin <[email protected]> wrote: > > > Hi Dan, > > > > From other side, attachments itself are correctly transferred by using MTOM > and Dispatch interface. > > What is missing is only xop:include elements in the message payload. > > Do you think it can be useful extension to provide interceptor checking for > specific configuration property and inserts xop:include elements (for example > based on XPath)? > > We could, yes, but I'm struggling to figure out an advantage to doing that > compared to just creating the proper messages up front. Doing this would > involve a bit of configuration for each client as you'd have to add in an > interceptor, configure in the the needed XPaths, there would be quite a bit of > performance overhead of evaluating xpaths and traversing over the structure. > > To me, it just makes more sense to have a set of utility methods that can be > used while that message is being built like: > > void addXOPElement(SOAPMessage msg, SOAPElement parent, QName qn, > DataSource src); void addXOPElement(SOAPMessage msg, SOAPElement > parent, QName qn, String mimeType, byte[]); > > (with multiple variants of the last parameters such as Image, Source, DOM, > etc... as needed) > > The utility methods would attach the data do the SOAPMessage as an > attachment (creating a CID, headers, etc...), create the element, create the > child xop:include, and fill in the attributes. > > Basically, if they were willing to have to call a "setOptimized(true)" on a > custom SOAPElement, I'm not sure why they wouldn't be able to call a utility > method that would actually do the optimization. > > Any time you have to do some sort of transformation of the message during the > streaming/marshaling, you're going to have some level of overhead. If that > overhead is easily avoided, does it make sense to do so? > > Dan > > > > > > > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Daniel Kulp [mailto:[email protected]] > >> Sent: Mittwoch, 26. Februar 2014 14:16 > >> To: [email protected]; Gumudavelli, Alekhya > >> Subject: Re: Query on CXF dispatch client with MTOM > >> > >> > >> I guess the more precise wording is that CXF implements "Support for > MTOM". > >> CXF doesn't process any of the XML to generate the xop:include or process > the > >> include elements. What CXF provides is support to setup the messaging > >> payload to allow for attachments and callbacks for the Databindings > >> to add attachments or read attachments. It's up to the various data > >> bindings > to figure > >> out if and how they implement the mtom portions. JAXB and Aegis both > >> support mtom. SDO and XMLBeans do not. Basically, it provides > >> "Support > >> for MTOM", but doesn't implement mtom stuff itself except for Aegis > >> as that's fully part of CXF. > >> > >> For the Dispatch using SOAPMessage or Source, it goes through via the > >> "Source" data binding which pretty much copies the data directly through. > It > >> does absolutely no xop:include processing at all. It doesn't even really > >> look > into > >> the contents of the XML at all. It just copies the XML events onto the > >> wire > >> directly. > >> > >> > >> Dan > >> > >> > >> > >> > >> On Feb 26, 2014, at 5:56 AM, Gumudavelli, Alekhya > >> <[email protected]> wrote: > >> > >>> Hi Dan, Andrei, > >>> > >>> Referring to below message from you, it indicates that core CXF has > >>> support > >> for MTOM. It is just that dispatch API does not have pointers to look > >> for such a config. > >>> If we try to expose that functionality which is already present in > >>> CXF somehow, we can achieve our goal. Isn't it? (We don't have to > >>> use SAAJ api ) > >> I have gone through CXF code from svn and did not find any specific > >> handling of <xop includes> anywhere. I could only find code snippets > >> that set content type to application/xop+xml. > >>> If what I assumed is right, could you point me to the classes that > >>> implement > >> it. > >>> > >>> "I got the issue now, sorry for delay. > >>> The problem is that if you use WSDL or Java first approaches, you > >>> say CXF > >> where inject a reference to sending binary data: > >>> > >>> - for WSDL using <element name="attachinfo" > type="xsd:base64Binary" > >> xmime:expectedContentTypes="application/octet-stream"/> > >>> > >>> - for java using annotation: > >>> > >>> @XmlMimeType("application/octet-stream") > >>> > >>> protected DataHandler imageData; > >>> > >>> In case of using Dispatch interface and SOAPMessage, user is > >>> responsible to > >> build complete SOAP message and, as a result, to insert <xop:Include > >> href> element. > >>> Currently CXF has no information where this element should be added > >>> in > >> SOAPMessage body. > >>> > >>> I think that could be a useful extension to provide additional > >>> property for > >> example in form of XPath and automate that for SOAPMessage as well. > >>> Patch is welcome. > >>> " > >>> > >>> Regards, > >>> Alekhya > >>> > >>> From: Daniel Kulp [mailto:[email protected]] > >>> Sent: Thursday, February 20, 2014 11:03 PM > >>> To: [email protected]; Gumudavelli, Alekhya > >>> Subject: Re: Query on CXF dispatch client with MTOM > >>> > >>> > >>> On Feb 20, 2014, at 3:55 AM, Gumudavelli, Alekhya > >> > <[email protected]<mailto:[email protected] > >> o > >> m>> wrote: > >>> > >>> > >>> hi Andrei, > >>> We are using JAXWS's SOAPElement to build the envelope. And in order > >>> to > >> MTOM optimize it, we need some class CXFSOAPElement in CXF api which > >> would have an "optimize()" method. > >>> > >>> Likely not possible. The SOAPElement things are very specific to > >>> whatever > >> SAAJ implementation that is picked up. Creation of the SOAPElements > >> should be done via the factory (usually the SOAPEnvelope/SOAPBody or via > the > >> Document object) that the SAAJ implementation provides. It's very > >> possible > >> that whatever implementation that is picked up would reject adding > >> any SOAPElement that wasn't created via it's own factories. (others > >> may "copy" the element over to one of it's own and thus loose the > >> custom methods anyway) > >>> > >>> > >>> > >>> optimize() on an element is expected to do the following - > >>> > >>> 1. Extract the attachment included within the SOAP message body and > >> send it as separate attachment part along with SOAP message. > >>> 2. Add an <xop:include href> element inside the element, this would > refer > >> to the attachment part. > >>> > >>> Developer must not add attachments as parts. Instead, CXF must be > >> intelligent enough to extract them and put <xop:include href>'s > >> wherever necessary. > >>> I understand that these are not currently supported in CXF and a > >>> patch if > >> provided by anybody must implement the above steps. Let me know if my > >> understanding is right. > >>> > >>> I don't see how the above can be done at all. As I said, CXF is happy > >>> to use > >> whatever SAAJ implementation we find with whatever restrictions that > >> may place. > >>> > >>> > >>> Since the SAAJ stuff implements the DOM API's, you could likely do a > >> element.setUserData(...) to stick a key on it. This could be checked > >> at > >> read/write time to figure out how to handle it. However, I would NOT have > >> this check done by default in CXF as doing a lookup for every element > >> at write time would slow things down for the 99% of the time that this is > >> not > needed. > >> It would likely be easiest to just have a static utility method that > >> would take the SOAPMessage object in, walks through the full dom > >> checking that property, replaces it with an include element, takes the data > and creates an attachment, > >> sticks that on the SOAPMessage, etc... You *MIGHT* be able to create a > CXF > >> interceptor that would grab the saaj model and pass to that method to > >> handle that. Not really sure. > >>> > >>> The next optimization beyond that would be to subclass the > >> W3CDOMStreamReader we have and perform that operation at the > >> appropriate reading events. Pass in a StaxSource with that reader as the > type > >> instead of the DOM. I'm not 100% sure this would always work as we do > some > >> levels of optimizations if we see the DOMStreamReader. > >>> > >>> > >>> The other thing to think about is on the return side. If the service > >>> returns > an > >> MTOM message, we won't do anything with it either . The SOAPMessage > >> returned from the Dispatch will have the xop:includes and the attachments > will > >> be as attachments. You'll need to do processing of the xops yourself. > >>> > >>> > >>> Dan > >>> > >>> > >>> > >>> Thanks, > >>> Alekhya > >>> > >>> From: Andrei Shakirin [mailto:[email protected]] > >>> Sent: Thursday, February 20, 2014 1:43 PM > >>> To: [email protected]<mailto:[email protected]> > >>> Cc: Gumudavelli, Alekhya > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi, > >>> > >>> I got the issue now, sorry for delay. > >>> The problem is that if you use WSDL or Java first approaches, you > >>> say CXF > >> where inject a reference to sending binary data: > >>> - for WSDL using <element name="attachinfo" > type="xsd:base64Binary" > >> xmime:expectedContentTypes="application/octet-stream"/> > >>> - for java using annotation: > >>> @XmlMimeType("application/octet-stream") > >>> protected DataHandler imageData; > >>> > >>> In case of using Dispatch interface and SOAPMessage, user is > >>> responsible to > >> build complete SOAP message and, as a result, to insert <xop:Include > >> href> element. > >>> Currently CXF has no information where this element should be added > >>> in > >> SOAPMessage body. > >>> > >>> I think that could be a useful extension to provide additional > >>> property for > >> example in form of XPath and automate that for SOAPMessage as well. > >>> Patch is welcome. > >>> > >>> Regards, > >>> Andrei. > >>> > >>> > >>> From: Gumudavelli, Alekhya [mailto:[email protected]] > >>> Sent: Dienstag, 18. Februar 2014 13:53 > >>> To: Andrei Shakirin; > >>> [email protected]<mailto:[email protected]> > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> Importance: High > >>> > >>> Hi Andrei, > >>> Any update on this. I raised a JIRA item on the same last week. > >>> Could > >> someone please look into it. > >>> https://issues.apache.org/jira/browse/CXF-5560 > >>> Let me know if you need more details on the issue. > >>> > >>> Regards, > >>> Alekhya > >>> > >>> From: Gumudavelli, Alekhya > >>> Sent: Thursday, February 13, 2014 11:42 AM > >>> To: Andrei Shakirin; > >>> [email protected]<mailto:[email protected]> > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi, > >>> > >>> I am attaching the client and service that I am using. > >>> MTOMClient.java is a > >> standalone Java program that I wrote to connect to a service that I > >> got from CXF samples apache-cxf-3.0.0-milestone1.rar > >>> ( apache-cxf-3.0.0-milestone1\samples\mtom ). links.txt is the file I am > >> trying to send as an MTOM attachment. > >>> > >>> I am also attaching MTOMClientBase64.java. It sends a base64 encoded > >>> data > >> of the attachment. > >>> > >>> Regards, > >>> Alekhya > >>> > >>> From: Andrei Shakirin [mailto:[email protected]] > >>> Sent: Wednesday, February 12, 2014 9:43 PM > >>> To: [email protected]<mailto:[email protected]> > >>> Cc: Gumudavelli, Alekhya > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi, > >>> > >>> Interesting. Any chance to create a small test case to reproduce that? > >>> > >>> Regards, > >>> Andrei. > >>> > >>> From: Gumudavelli, Alekhya [mailto:[email protected]] > >>> Sent: Mittwoch, 12. Februar 2014 14:26 > >>> To: Andrei Shakirin; > >>> [email protected]<mailto:[email protected]> > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi, > >>> I don't find any difference between my client code and > >> https://svn.apache.org/repos/asf/cxf/branches/2.7.x- > >> fixes/systests/jaxws/src/test/java/org/apache/cxf/systest/swa/ClientS > >> erverSwa Test.java except that I am doing an additional setting > >> MTOMEnabled property to true. > >>> > >>> Can you give me any MTOM specific sample test (not just SWA). I > >>> would like > >> to try that out directly. I had searched in cxf/systest/ repository > >> but could not find any. I see that all MTOM tests in the repo use stubs and > not dispatch API. > >>> > >>> Or can you point me to the internal CXF code / class that takes care > >>> of adding > >> <xop include> element. I would like to debug and understand why is it > >> not xop'ing it. > >>> We are revamping our entire stack to use CXF and this issue is > >>> hindering us > >> from implementing MTOM with CXF, one of the important features for > clients. > >>> > >>> Thanks much for the quick responses Andrei! > >>> > >>> Alekhya > >>> > >>> From: Andrei Shakirin [mailto:[email protected]] > >>> Sent: Tuesday, February 11, 2014 11:06 PM > >>> To: [email protected]<mailto:[email protected]> > >>> Cc: Gumudavelli, Alekhya > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi, > >>> > >>> It is quite difficult to say what exactly wrong without your test case. > >>> Could you run the system test I referenced in last mail and try to > >>> find the > >> difference between test and your code? > >>> > >>> Regards, > >>> Andrei. > >>> > >>> From: Gumudavelli, Alekhya [mailto:[email protected]] > >>> Sent: Dienstag, 11. Februar 2014 12:54 > >>> To: Andrei Shakirin; > >>> [email protected]<mailto:[email protected]> > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi Andrei, > >>> I am doing exactly the way you are referring. The service is not > >>> able to > >> recognize attachment. > >>> > >>> Below is my service method . It fails to process attachment as the > >>> parameter > >> "attachinfo" does not hold the attachment we have sent. This works > >> well if I manually insert <attachinfo> element by linking it with > >> content-id. > >>> > >>> public void testDataHandler(Holder<String> name, Holder<DataHandler> > >> attachinfo) { > >>> if(attachinfo.value==null) > >>> {System.out.println("attachinfo.value > >>> is null"); //This gets > >> executed > >>> return;} > >>> InputStream mtomIn = attachinfo.value.getInputStream(); > >>> ByteArrayOutputStream out = new > >>> ByteArrayOutputStream(); and so on.... > >>> > >>> Also, in the below line we can use any random name to set content id. > >>> Isn't > it? > >>> > >>> att.setContentId("<attach1=c187f5da-fa5d-4ab9-81db- > >> 33c2bb855201@apache > >>> .org<mailto:attach1=c187f5da-fa5d-4ab9-81db- > >> [email protected]>>" > >>> ); > >>> > >>> Could you please help me out with this issue > >>> > >>> > >>> Below is the screenshot of my request in TCP mon - > >>> > >>> > >>> > >>> > >>> Regards, > >>> Alekhya > >>> > >>> From: Andrei Shakirin [mailto:[email protected]] > >>> Sent: Monday, February 10, 2014 9:57 PM > >>> To: [email protected]<mailto:[email protected]> > >>> Cc: Gumudavelli, Alekhya > >>> Subject: RE: Query on CXF dispatch client with MTOM > >>> > >>> Hi, > >>> > >>> I do not think that you should add MTOM <include> manually. > >>> > >>> It should be enough to activate MTOM and add attachment part in > >>> following > >> way: > >>> > >>> DataHandler dh1 = new DataHandler(new > >>> ByteArrayDataSource(bigBytes, "text/plain")); > >>> > >>> AttachmentPart att = msg.createAttachmentPart(dh1); > >>> att.setContentId("<attach1=c187f5da-fa5d-4ab9-81db- > >> [email protected]<mailto:attach1=c187f5da-fa5d-4ab9-81db- > >> [email protected]>>"); > >>> msg.addAttachmentPart(att); > >>> > >>> See the testSwaTypesWithDispatchAPI() in > >> https://svn.apache.org/repos/asf/cxf/branches/2.7.x- > >> fixes/systests/jaxws/src/test/java/org/apache/cxf/systest/swa/ClientS > >> erverSwa > >> Test.java for details. > >>> > >>> Regards, > >>> Andrei. > >>> > >>> > >>> From: Gumudavelli, Alekhya [mailto:[email protected]] > >>> Sent: Montag, 10. Februar 2014 08:36 > >>> To: Andrei Shakirin > >>> Cc: [email protected]<mailto:[email protected]> > >>> Subject: Query on CXF dispatch client with MTOM > >>> > >>> Hi Andrei, team > >>> > >>> I am writing a CXF client with MTOM by using dynamic dispatch style > >>> of > >> service invocation. I understand that dynamic dispatch requires > >> request message to be constructed manually. > >>> But I would like to avoid manual insertion of <inc:include href> XOP > >>> element > >> in the SOAP message to enable MTOM. > >>> > >>> I am currently doing the following steps to generate a CXF mtom client > >>> 1. Enable MTOM using > >>> > >>> ((SOAPBinding)binding).setMTOMEnabled(true); > >>> > >>> 2. Construct SOAP request message programmatically > >>> > >>> SOAPMessage request = MessageFactory.newInstance().createMessage(); > >>> //create attachment and add it to request AttachmentPart attach = > >>> request.createAttachmentPart(new DataHandler(new > >> > FileDataSource("F:\\CXF3\\CXF3\\src\\me.bmp<smb://CXF3/CXF3/src/me.bm > >> p> > >> "))); > >>> attach.setContentId("image"); > >>> request.addAttachmentPart(attach); > >>> > >>> SOAPElement operation = body.addChildElement("testDataHandler", "typ", > >>> "http://cxf.apache.org/mime/types";); > >>> > >>> /*Here, I am creating the SOAP body with appropriate nodes needed > >>> for MTOM - <inc:include href="image". . . */ > >>> > >>> SOAPElement value1 = operation.addChildElement("attachinfo", > >>> "tns","http://cxf.apache.org/mime/types";); > >>> SOAPElement xop = > >>> value1.addChildElement("Include","inc","http://www.w3.org/2004/08/xo > >>> p/ include"); xop.addAttribute(QName.valueOf("href"),"cid:image"); > >>> > >>> Generated request message : > >>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; > >> xmlns:typ="http://cxf.apache.org/mime/types";> > >>> <soapenv:Header > >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"/> > >>> <soap:Body> > >>> <typ:testDataHandler> > >>> <tns:attachinfo > >>> xmlns:tns="http://cxf.apache.org/mime/types";><inc:Include > >>> xmlns:inc="http://www.w3.org/2004/08/xop/include"; > >>> href="cid:image"/></tns:attachinfo> > >>> </typ:testDataHandler> > >>> </soap:Body> > >>> </soap:Envelope> > >>> > >>> The above request works well. However, manual inclusion of DOM > >>> elements > >> like this does not appear clean and maintainable. Could you tell me > >> how else can we achieve this to generate the request dynamically? > >>> > >>> I have the same issue with SWA CXF dispatch client where I am > >>> including > >> <cid:image> node programmatically which I want to avoid. > >>> > >>> Thanks, > >>> Alekhya Gumudavelli > >>> > >>> -- > >>> Daniel Kulp > >>> [email protected]<mailto:[email protected]> - http://dankulp.com/blog > >>> Talend Community Coder - > >>> http://coders.talend.com<http://coders.talend.com/> > >>> > >> > >> -- > >> Daniel Kulp > >> [email protected] - http://dankulp.com/blog Talend Community Coder - > >> http://coders.talend.com > > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
