You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Willem Jiang (JIRA)" <ji...@apache.org> on 2014/08/15 11:08:19 UTC

[jira] [Resolved] (CAMEL-7701) Chaining cxfrs endpoints

     [ https://issues.apache.org/jira/browse/CAMEL-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Willem Jiang resolved CAMEL-7701.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.14.0
                   2.13.3
                   2.12.5

> 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
>            Assignee: Willem Jiang
>             Fix For: 2.12.5, 2.13.3, 2.14.0
>
>
> 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)