Hello,
thanks for your help. The suggested workaround works fine as long as both
cxf:components are bound to the same WSDL.
What are the recommended steps, if an existing web service should be
provided by a new contract (WSDL of first cxf:component differs from WSDL
of second cxf:component).
I think you need to set the mode back to PAYLOAD mode inside the second
processor (convertResponse) until CAMEL-3420 is fixed and delivered. I
added a unit test for your reference.
https://svn.apache.org/repos/asf/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/Cx
Hello,
the conversion does not help. It seams, that the second cxf-component
(POJO) changes the camel exchange in a way the first cxf-component
(PAYLOAD) can't deal with. For simplicity, I have bound both components to
the same WSDL, but even if I wrap the response from the second
cxf-componen
Mixing of POJO and PAYLOAD is probably fine but you have to do some
conversion (e.g. in a processor). You know the message body for POJO
mode is List and for PAYLOAD mode is CxfPayload. So, it needs
conversion from a List to CxfPayload for the request and convert
back from CxfPayload to List
Hello,
in my integration prototype an existing web-service should be adapted to
an other contract. Therefore, I have a cxf:consumer(dataFormat=PAYLOAD;
the associated cxf:endpoint definition references a WSDL but no service
class) and a cxf:producer (the associated cxf:endpoint references a
se
