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] >> 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/ClientServerSwa >> 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/ClientServerSwa >> 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.bmp> >> "))); >>> 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/xop/ >>> 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
