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]>> 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/ClientServerSwaTest.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("<[email protected]<mailto:[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("<[email protected]<mailto:[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/ClientServerSwaTest.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/>
