Hi Hadrian,
Sorry, my terminology in the post was confusing. There are no requests and
replies in Camel, of course. By 'request', I was referring to the In message
that is destined to become the request to the "cxf:bean:MyService" service
and by 'reply', I was referring to the message returned from the
"cxf:bean:MyService" endpoint (which propagates as an In message in the
second half of the route).
Here is a simpler (working) example, which might be clearer:
from("jetty:http://localhost:8080/foo";)
.setBody(constant(">b<Hello World\</b\>"));
If you point your browser at the address, http://localhost:8080/foo, you'll
get a blank page (i.e. no reply), because this route does not generate an
Out message. Now modify the route to the following:
from("jetty:http://localhost:8080/foo";)
.setBody(constant("\<b\>Hello World\</b\>"))
.transform(body());
If you now point your browser at http://localhost:8080/foo, you'll see the
string "Hello World", because the In message has been copied to the Out
message by transform(body()) (which is semantically equivalent to the
proposed echo()).
Now this example is rather contrived, because you could have made it work in
the first place by using setOutBody() instead of setBody(). But in many
cases, it could happen that the last processor in your route happens to
produce an In message instead of an Out message. In this case, you'd have to
finish your route with transform(body()) (or, equivalently, echo()), to copy
the In message to the Out message.
My hypothesis is that this _might_ be a common pattern for routes that
process InOut exchanges, in which case an echo() processor would be a handy
convenience. On the other hand, maybe my sample route is actually an exotic
rarity :-). I noticed that the Camel doc has more examples of routes that
process InOnly exchanges than InOut exchanges.
-
Fintan
Hadrian Zbarcea wrote:
>
> Hi Fintan,
>
> I don't see how this would help. There is no request and reply per
> se, there is just an exchange that has messages. During processing
> the in and out messages will change many times and whatever will be
> the out message at the end of the pipeline will be sent as a reply to
> the caller. As such, with or without echo(), same thing will happen.
>
> I hope I didn't misunderstand your point.
> Hadrian
>
>
> On Aug 21, 2008, at 6:48 AM, Fintan Bolton wrote:
>
>>
>> Hi,
>>
>> Is there a case for adding an echo() processor to the fluent DSL,
>> where the
>> echo() processor simply copies the In message to the Out message?
>> This could
>> be useful for capping off routes that process InOut exchanges. For
>> example:
>>
>>
>> from("jetty:http://FooHost/Bar";)
>> .process(...).process(...)
>> .to("cxf:bean:MyService")
>> .process(...).process(...)
>> .echo();
>>
>> Where this example wraps a CXF Web service endpoint. The first
>> couple of
>> processors, process(..), do work on the Web service _request_, and the
>> processors that come after to(...) do work on the Web service
>> _reply_. At
>> the end of the route, you need to reflect the the reply back to the
>> JETTY
>> endpoint. An echo() processor would be handy for this purpose.
>>
>> I realize that this is not tremendously critical, because you could
>> already
>> use 'transform(body())' to achieve the same effect. But using an
>> echo()
>> processor is possibly more elegant.
>>
>> -
>> Fintan
>> --
>> View this message in context:
>> http://www.nabble.com/echo%28%29-processor-tp19086322s22882p19086322.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
>
:-):-)
--
View this message in context:
http://www.nabble.com/echo%28%29-processor-tp19086322s22882p19089792.html
Sent from the Camel - Users mailing list archive at Nabble.com.
