cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Query on CXF dispatch client with MTOM
Date Wed, 26 Feb 2014 16:29:49 GMT

On Feb 26, 2014, at 8:34 AM, Andrei Shakirin <ashakirin@talend.com> 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: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
> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message