That's because other components in Camel 2.0 will use the
Exchange.HTTP_URI and Exchange.HTTP_PATH to do some work.
Maybe we can add an option in http endpoint to ignore these two headers
if you still want to use the HTTP bridge as Camel 1.x.
Willem
_Jens wrote:
Hi,
in Camel 1.x you could write a simple HTTP bridge like this:
CamelContext camelContext = new DefaultCamelContext();
camelContext.addRoutes(new RouteBuilder() {
@Override
public void configure() throws Exception {
from("jetty:http://localhost:8435/path1";).to("http://localhost:8435/path2";);
from("jetty:http://localhost:8435/path2";).transform().constant("OK");
}
});
camelContext.start();
ProducerTemplate producerTemplate =
camelContext.createProducerTemplate();
InputStream result = (InputStream)
producerTemplate.requestBody("http://localhost:8435/path1";, "Hello");
assertEquals("OK", IOUtils.toString(result));
in Camel 2.0 this doesn't work anymore because the Exchange.HTTP_URI and
Exchange.HTTP_PATH are set by the consumer that received the initial
request. The HttpProducer that is called because of the to() then "thinks"
those header properties were set to define the actual destination and sends
the data to "/path1/path1", which leads to an error. You have to explicitly
remove those properties from the exchange to make it work:
from("jetty:http://localhost:8435/path1";)
.removeHeader(Exchange.HTTP_URI)
.removeHeader(Exchange.HTTP_PATH)
.to("http://localhost:8435/path2";);
I can't think of any use for this behavior and it is rather surprising.
However, I understand that it might be a side effect that we have to live
with because the header property names are now shared between the endpoints.
Anyway, is this the way it is supposed to work now or is it worth to submit
a bug report for this? Are there any other properties that should be removed
to ensure that the to() really sends it to the destination it is supposed
to?
Thanks,
Jens
