You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Joe Qiang Luo (JIRA)" <ji...@apache.org> on 2015/10/22 20:46:27 UTC

[jira] [Created] (CAMEL-9246) camel-cxf proxy with MTOM does not get attachment back when RPC/literal style WSDL used

Joe Qiang Luo created CAMEL-9246:
------------------------------------

             Summary: camel-cxf proxy with MTOM does not get attachment back when RPC/literal style WSDL used
                 Key: CAMEL-9246
                 URL: https://issues.apache.org/jira/browse/CAMEL-9246
             Project: Camel
          Issue Type: Bug
          Components: camel-cxf
    Affects Versions: 2.15.1
         Environment: CXF 3.0.4
            Reporter: Joe Qiang Luo


I have a camel-cxf proxy test case with MTOM enabled. The WSDL used in the project is RPC/Literal style. However, I was unable to get attachment back via response. Please take a look at the test case for more detail.

After some debugging, it looks like that camel-cxf producer did get attachment back. However, there were two attachment related parts. One part had no attachment (empty) but had correct "Content-ID". The other part did contain entire attachment but had a rather different "Content-ID". For instance:

{code}
19:30:47,110 | INFO  | qtp565617691-367 | IMtomExample                     | 118 - org.apache.cxf.cxf-core - 3.0.4.redhat-620133 | Outbound Message
---------------------------
ID: 63
Response-Code: 200
Encoding: UTF-8
Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:f108bc3f-549a-4baa-ab00-757ff837aacf"; start="<ro...@cxf.apache.org>"; start-info="text/xml"
Headers: {accept-encoding=[gzip,deflate], breadcrumbId=[ID-jluomac-52985-1445511717614-11-8], Host=[localhost:7777], Server=[Jetty(8.1.15.v20140411)], User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)]}
Payload: --uuid:f108bc3f-549a-4baa-ab00-757ff837aacf
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <ro...@cxf.apache.org>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns1:doMtomResponse xmlns:ns1="http://cxf.example.com/"><parameters xmlns:ns2="http://cxf.example.com/"><output>soapui-splash.png</output><dataLength>27186</dataLength><data><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:15839364-d75d-4cbe-a163-40838bca762a-31@cxf.apache.org"/></data></parameters></ns1:doMtomResponse></soap:Body></soap:Envelope>
--uuid:f108bc3f-549a-4baa-ab00-757ff837aacf
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <e4...@cxf.apache.org>
Content-Disposition: attachment;name="soapui-splash.png"

<-- soapui-splash.png binary attachment starts here -->
...
...
<-- soapui-splash.png binary attachment ends here -->

--uuid:f108bc3f-549a-4baa-ab00-757ff837aacf
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <15...@cxf.apache.org>
Content-Disposition: attachment;name="soapui-splash.png"

<-- no binary attachment here. empty -->

--uuid:f108bc3f-549a-4baa-ab00-757ff837aacf--
--------------------------------------
{code}

And the response message returned was:
{code}
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <ns1:doMtomResponse xmlns:ns1="http://cxf.example.com/">
         <parameters xmlns:ns2="http://cxf.example.com/">
            <output>soapui-splash.png</output>
            <dataLength>27186</dataLength>
            <data>
               <xop:Include href="cid:15839364-d75d-4cbe-a163-40838bca762a-31@cxf.apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
            </data>
         </parameters>
      </ns1:doMtomResponse>
   </soap:Body>
</soap:Envelope>
{code}

Because the response pointed to the "Content-ID" of 
{code}
<xop:Include href="cid:15839364-d75d-4cbe-a163-40838bca762a-31@cxf.apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
{code}

and the parts identified by the "Content-ID: <15...@cxf.apache.org>" was actually empty. Therefore, client can not get the attachment back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)