You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2019/03/29 18:37:38 UTC
Dealing with Attachments in CXF JAX-WS Clients
Hi,
I'm looking to integrate with an existing webservice that uses attachments
for its handling of binary content. I've enabled mtom on my client. I've
tested the service using SoapUI and I can see that it properly handles the
attachment when using the attachment option in SoapUI.
When I try to replicate this request in CXF, it fails. But I notice the
call CXF makes is vastly different than the one I see in SoapUI. For
instance, CXF adds the attachment object as an element in the SOAP call,
but SoapUI does not.
The WSDL has 2 parts to it, one with the request xml and a second wsdl:part
with name attachment and type xs:base64Binary. I can see the mime related
parts for the attachment object being set to application/octet-stream.
I'm wondering if there's something special I have to do to enable this
service to work from the client perspective?
Thanks,
John
Re: Dealing with Attachments in CXF JAX-WS Clients
Posted by "John D. Ament" <jo...@apache.org>.
So here's something of interest - I think some of the behavior has to do with how the MTOM field is defined. Most examples, including the one used by CXF have it as a field within a request object. in my case, the SOAP service is exposing the MTOM attribute as a separate argument. this is what my wsdl operation looks like
<wsdl:operation name="createContent">
<soap:operation soapAction="http://www.supercompany.com/content/creation/2/createContent"/>
<wsdl:input>
<mime:multipartRelated>
<mime:part name="request">
<soap:body parts="request" use="literal"/>
</mime:part>
<mime:part name="attachment">
<mime:content part="attachment" type="*/*"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
Note that I added the xmime attribute to see if that helped with the processing but didn't.
Now that I can grab the raw data, basically what we're seeing is the generated SOAP call
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="1">
<wsse:UsernameToken /> <!-- skipped for brevity -->
</wsse:Security>
</soap:Header>
<soap:Body>
<ns3:createContentRequest xmlns="http://www.supercompany.com/content/creation/bi/2/" xmlns:ns2="http://www.supercompany.com/content/2/" xmlns:ns3="http://www.supercompany.com/content/creation/2/" xmlns:ns4="http://www.supercompany.com/common/status/1/">
<createContentRequest /> <!-- skipped -->
</ns3:createContentRequest>
<ns3:attachment xmlns="http://www.supercompany.com/content/creation/bi/2/" xmlns:ns2="http://www.supercompany.com/content/2/" xmlns:ns3="http://www.supercompany.com/content/creation/2/" xmlns:ns4="http://www.supercompany.com/common/status/1/">
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b3f6177b-ec45-4bc6-8517-2f8651525cee-1@www.supercompany.com"/>
</ns3:attachment>
</soap:Body>
</soap:Envelope>
Has the section starting with <ns3:attachment> which no one is expecting and that seems to be the issue, instead the raw content should just be parsed from the body of the message (which we can see is coming correctly).
Thanks,
John
On 2019/03/29 18:37:38, "John D. Ament" <jo...@apache.org> wrote:
> Hi,
>
> I'm looking to integrate with an existing webservice that uses attachments
> for its handling of binary content. I've enabled mtom on my client. I've
> tested the service using SoapUI and I can see that it properly handles the
> attachment when using the attachment option in SoapUI.
>
> When I try to replicate this request in CXF, it fails. But I notice the
> call CXF makes is vastly different than the one I see in SoapUI. For
> instance, CXF adds the attachment object as an element in the SOAP call,
> but SoapUI does not.
>
> The WSDL has 2 parts to it, one with the request xml and a second wsdl:part
> with name attachment and type xs:base64Binary. I can see the mime related
> parts for the attachment object being set to application/octet-stream.
>
> I'm wondering if there's something special I have to do to enable this
> service to work from the client perspective?
>
> Thanks,
>
> John
>
Re: Dealing with Attachments in CXF JAX-WS Clients
Posted by "John D. Ament" <jo...@apache.org>.
Hi Daniel
So that fixed part of my issue, but not sure if it brought me steps forward or back.
So now when I add the swa bindings to the WSDL and regenerate, I do see a data handler argument now instead of a byte[] argument, however now the outgoing soap requests have the binary content in the attachment field instead of streamed as a second multipart attribute. The hope was to remove that attachment field from the outgoing soap request and see the content of the attachment as a second multipart.
I did verify all mtom settings were disabled when rerunning it.
Thanks,
John
On 2019/04/01 16:42:53, Daniel Kulp <dk...@apache.org> wrote:
>
> I think you are confusing a couple of specs….. MTOM and Soap W/ Attachments are actually two separate specs and are handled differently.
>
> For SwA, you wouldn’t turn on MTOM. CXF should be able to look in the WSDL and as long as mime things are properly and completely defined in the WSDL, it should use that. However, it also requires you to run the wsdl2java stuff a bit differently as you need a binding file that turns on the “enableMIMEContent” capabilities.
>
> If you look in our repo in the testutils/src/main/resources/wsdl directory, there is a swa-mime-binding.xml binding file that would go along with the swa-mime.wsdl file. Use that as the starting point to re-generate the interfaces and see if that changes anything. If you want to dig into the code that tests things, that would be systests/jaxws/src/test/java/org/apache/cxf/systest/swa/ClientServerSwaTest.java.
>
> Dan
>
>
>
> > On Mar 29, 2019, at 2:37 PM, John D. Ament <jo...@apache.org> wrote:
> >
> > Hi,
> >
> > I'm looking to integrate with an existing webservice that uses attachments
> > for its handling of binary content. I've enabled mtom on my client. I've
> > tested the service using SoapUI and I can see that it properly handles the
> > attachment when using the attachment option in SoapUI.
> >
> > When I try to replicate this request in CXF, it fails. But I notice the
> > call CXF makes is vastly different than the one I see in SoapUI. For
> > instance, CXF adds the attachment object as an element in the SOAP call,
> > but SoapUI does not.
> >
> > The WSDL has 2 parts to it, one with the request xml and a second wsdl:part
> > with name attachment and type xs:base64Binary. I can see the mime related
> > parts for the attachment object being set to application/octet-stream.
> >
> > I'm wondering if there's something special I have to do to enable this
> > service to work from the client perspective?
> >
> > Thanks,
> >
> > John
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>
Re: Dealing with Attachments in CXF JAX-WS Clients
Posted by Daniel Kulp <dk...@apache.org>.
I think you are confusing a couple of specs….. MTOM and Soap W/ Attachments are actually two separate specs and are handled differently.
For SwA, you wouldn’t turn on MTOM. CXF should be able to look in the WSDL and as long as mime things are properly and completely defined in the WSDL, it should use that. However, it also requires you to run the wsdl2java stuff a bit differently as you need a binding file that turns on the “enableMIMEContent” capabilities.
If you look in our repo in the testutils/src/main/resources/wsdl directory, there is a swa-mime-binding.xml binding file that would go along with the swa-mime.wsdl file. Use that as the starting point to re-generate the interfaces and see if that changes anything. If you want to dig into the code that tests things, that would be systests/jaxws/src/test/java/org/apache/cxf/systest/swa/ClientServerSwaTest.java.
Dan
> On Mar 29, 2019, at 2:37 PM, John D. Ament <jo...@apache.org> wrote:
>
> Hi,
>
> I'm looking to integrate with an existing webservice that uses attachments
> for its handling of binary content. I've enabled mtom on my client. I've
> tested the service using SoapUI and I can see that it properly handles the
> attachment when using the attachment option in SoapUI.
>
> When I try to replicate this request in CXF, it fails. But I notice the
> call CXF makes is vastly different than the one I see in SoapUI. For
> instance, CXF adds the attachment object as an element in the SOAP call,
> but SoapUI does not.
>
> The WSDL has 2 parts to it, one with the request xml and a second wsdl:part
> with name attachment and type xs:base64Binary. I can see the mime related
> parts for the attachment object being set to application/octet-stream.
>
> I'm wondering if there's something special I have to do to enable this
> service to work from the client perspective?
>
> Thanks,
>
> John
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>