Xilai Dai created CAMEL-12252:
---------------------------------

             Summary: Dynamic setting the DESTINATION_OVERRIDE_URL doesn't work 
on CXFRS producer
                 Key: CAMEL-12252
                 URL: https://issues.apache.org/jira/browse/CAMEL-12252
             Project: Camel
          Issue Type: Bug
          Components: camel-cxfrs
    Affects Versions: 2.20.2, 2.19.4, 2.18.5, 2.17.0
         Environment: Java 8
            Reporter: Xilai Dai


Given the sample MyProcessor, setting the DESTINATION_OVERRIDE_URL dynamically 
during the invoke:
{code}
public void process(Exchange exchange) throws Exception {
    String env = (String)exchange.getIn().getHeader("Environnement");
    if (env.equalsIgnoreCase("DEV")) {
        exchange.getIn().setHeader(exchange.DESTINATION_OVERRIDE_URL,
            "http://esbdev11.local:8080/server1/metaServlet";);
    } else {
        exchange.getIn().setHeader(exchange.DESTINATION_OVERRIDE_URL,
            "http://esblab11.local:8080/server2/metaServlet";);
    }
}
{code}

Given the sample Route:
{code}
        from("cxfrs:bean:MyREST")
        .process(new HeaderProcessor())
        .setHeader("Environnement")
        .simple("${header.http_query[env][0]}")
        .process(new MyProcessor())
        .setHeader(org.apache.camel.Exchange.HTTP_METHOD, constant("GET"))
        .setHeader(org.apache.camel.Exchange.ACCEPT_CONTENT_TYPE, 
constant("*/*"))
        .setHeader(org.apache.camel.Exchange.HTTP_PATH, constant("/"))
        .to("cxfrs:bean:restClient?maxClientCacheSize=5");
{code}

Send request to cxfrs:bean:MyREST with different http header "dev", then the 
cxfrs:bean:restClient always make call to the last setting Address.

(Only it works as expected when setting maxClientCacheSize=0 on the 
cxfrs:bean:restClient)

There is no this issue on Camel 2.16.x, but start problem from Camel 2.17.x and 
later versions. Investigations show that the CxfRsEndpoint becoming Singleton 
after CAMEL-9628, that explain why the last Address setting always applied.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to