camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Jiang (JIRA)" <>
Subject [jira] [Assigned] (CAMEL-7701) Chaining cxfrs endpoints
Date Fri, 15 Aug 2014 03:25:18 GMT


Willem Jiang reassigned CAMEL-7701:

    Assignee: Willem Jiang

> Chaining cxfrs endpoints
> ------------------------
>                 Key: CAMEL-7701
>                 URL:
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.13.2, Future
>         Environment: JDK7 / Windows7
> OpenJDK /Ubuntu Precise
>            Reporter: Benjamin BONNET
>            Assignee: Willem Jiang
> 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

View raw message