Benjamin BONNET created CAMEL-7701:
--------------------------------------
Summary: Chaining cxfrs endpoints
Key: CAMEL-7701
URL: https://issues.apache.org/jira/browse/CAMEL-7701
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.13.2, Future
Environment: JDK7 / Windows7
OpenJDK /Ubuntu Precise
Reporter: Benjamin BONNET
Hi,
chaining 2 cxfrs endpoints in a route reveals 2 problems :
- proxy-client method choice in producer (CxfRsProducer.findRightMethod) is way
too restrictive : the choice is based on the name and the exact type of the
parameters. As a consequence, if parameters type transmitted are compatible
(i.e. extend the signature parameter types) with the method signature but are
not the very ones of the signature, the operation will not be found.
That problem occurs when you chain 2 cxfrs endpoints having an InputStream
parameter since cxf uses DelegatingInputStream to handle received InputStreams.
That problem may also occur for any ".to()" cxfrs endpoint if the message body
uses subtypes of the parameters.
- transmitting Content-Type header from camel to CXFRS request in
DefaultCxfRsBinding may cause trouble for multipart messages : actually, if
Content-Type contains a boundary defintion (which is the case when you chain
cxfrs endpoints), that definition will be included into the Content-Type
transmitted (in addition with the one generated during binding). That throws an
exception since the "old" boundary is not used in the transmitted message. NB :
header propagation was not enforced in 2.13.2 but it is enforced in head.
I developped a JUnit test that shows such failures in the case of a cxfrs
endpoint chaining, and some code that prevents them. I am going to submit them
on github.
Regards
--
This message was sent by Atlassian JIRA
(v6.2#6252)
