cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <ashaki...@talend.com>
Subject RE: Query on CXF dispatch client with MTOM
Date Wed, 26 Feb 2014 13:34:41 GMT
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:dkulp@apache.org]
> Sent: Mittwoch, 26. Februar 2014 14:16
> To: users@cxf.apache.org; 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
> <Alekhya.Gumudavelli@in.pega.com> 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:dkulp@apache.org]
> > Sent: Thursday, February 20, 2014 11:03 PM
> > To: users@cxf.apache.org; Gumudavelli, Alekhya
> > Subject: Re: Query on CXF dispatch client with MTOM
> >
> >
> > On Feb 20, 2014, at 3:55 AM, Gumudavelli, Alekhya
> <Alekhya.Gumudavelli@in.pega.com<mailto:Alekhya.Gumudavelli@in.pega.co
> 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:ashakirin@talend.com]
> > Sent: Thursday, February 20, 2014 1:43 PM
> > To: users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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:Alekhya.Gumudavelli@in.pega.com]
> > Sent: Dienstag, 18. Februar 2014 13:53
> > To: Andrei Shakirin; users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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; users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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:ashakirin@talend.com]
> > Sent: Wednesday, February 12, 2014 9:43 PM
> > To: users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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:Alekhya.Gumudavelli@in.pega.com]
> > Sent: Mittwoch, 12. Februar 2014 14:26
> > To: Andrei Shakirin; users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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:ashakirin@talend.com]
> > Sent: Tuesday, February 11, 2014 11:06 PM
> > To: users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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:Alekhya.Gumudavelli@in.pega.com]
> > Sent: Dienstag, 11. Februar 2014 12:54
> > To: Andrei Shakirin; users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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-
> 33c2bb855201@apache.org>>"
> > );
> >
> > 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:ashakirin@talend.com]
> > Sent: Monday, February 10, 2014 9:57 PM
> > To: users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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-
> 33c2bb855201@apache.org<mailto:attach1=c187f5da-fa5d-4ab9-81db-
> 33c2bb855201@apache.org>>");
> >        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:Alekhya.Gumudavelli@in.pega.com]
> > Sent: Montag, 10. Februar 2014 08:36
> > To: Andrei Shakirin
> > Cc: users@cxf.apache.org<mailto:users@cxf.apache.org>
> > 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
> > dkulp@apache.org<mailto:dkulp@apache.org> - http://dankulp.com/blog
> > Talend Community Coder -
> > http://coders.talend.com<http://coders.talend.com/>
> >
> 
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com


Mime
View raw message