camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel 2.0 Async Findings - Roadmap to a solution
Date Thu, 30 Apr 2009 12:58:04 GMT

Its me again. Yeah I am due for a run in due time, but just wanted to
demo something that is either powerful or scary

The code below uses the same route. But as we request a body and we
have declared we want the response as a String.class (the last
Then Camel is "clever" or "scary" to use the Future to wait and get
the result and convert the body to the desired type, eg a String.

So the routing is really divided into sync/async but the end user sees
it as a single sync.

    public void testAsyncRouteWithTypeConverted() throws Exception {
        MockEndpoint mock = getMockEndpoint("mock:result");
        mock.expectedBodiesReceived("Bye World");

        // send a request reply to the direct start endpoint, but will use
        // future type converter that will wait for the response
        String response = template.requestBody("direct:start",
"Hello", String.class);
        assertEquals("Bye World", response);


So whats next is that you can just pass in the Future<String.class> to
instruct Camel that you want the future handle back
and that it should return a String as the response.

Then Camel should be able to take it from there. With the future
handle the caller gets back in control when the routes hits the
async() DSL.
And can do other work as he like.

And when he want the response, he just:
Future<String> future = template.requestBody("direct:start", "Hello",

String response = future.get();

But then I guess this is impossible due to type erasure in java generics :(
No its not!!!

Okay time to hit the streets

Claus Ibsen
Apache Camel Committer

Open Source Integration:
Apache Camel Reference Card:

View raw message