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)?
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
