[
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029340#comment-16029340
]
Joerg Kessler commented on CXF-7388:
------------------------------------
No, I did not try that. It seems that the interceptor that tests the number of
attachments is not called anymore. That is strange. In the log there is still
no MTOM attachment visble, right? The error occurs because the response does
not fit to the WSDL I guess the test is still not perfect. I could use a one
way WSDL where there is no response. The original WSDL I used was built that
way.
> Problem with MTOM in Camel-CXF
> ------------------------------
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.1.9
> Reporter: Joerg Kessler
> Fix For: 3.2.0
>
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the
> Camel-CXF producer. To test it I created a simple route using Camel test
> infrastructure where the producer uses a WSDL with base64 encoded payload
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6";
> start="<[email protected]>"; start-info="text/xml"
> Headers: {Accept=[*/*],
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1],
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487],
> content-type=[multipart/related; type="application/xop+xml";
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6";
> start="<[email protected]>"; start-info="text/xml"],
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""],
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: <[email protected]>
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><typ:testXop
>
> xmlns:typ="http://cxf.apache.org/mime/types";><typ:name>?</typ:name><typ:attachinfo>U1VDQ0VTUw==</typ:attachinfo></typ:testXop></soap:Body></soap:Envelope>
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
> <cxf:cxfEndpoint id="clientEndpoint"
> address="http://localhost:8770/cxf/mtom"; bus="ClientBus"
> wsdlURL="wsdl/mtom_xop.wsdl">
> <cxf:properties>
> <entry key="dataFormat" value="PAYLOAD" />
> <entry key="defaultOperationName" value="testXop" />
> <entry key="defaultOperationNamespace"
> value="http://cxf.apache.org/mime"/>
> <entry key="mtom-enabled" value="true" />
> </cxf:properties>
> </cxf:cxfEndpoint>
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared
> the execution of the relevant interceptors in Camel-CXF and CXF and found one
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked
> that the data binding is implemented by the class
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF
> sets in CxfEndpoint the binding to
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from
> JAXBDataBinding but of course is a different class. This seems to prevent the
> completion of the MTOM conversion. I changed the code locally so that now all
> subclasses are accepted and now the attachment processing gets really called.
> But now the next problem apears; HybridSourceDataBinding.createWriter()
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not
> supported.
> at
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF.
> Therefore please forward it to Camel if the problem is locarted there.
> Best Regards,
> Jörg
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
