Hi The static solution is neat however it is not avail for the Spring XML routing.
But I like the idea, but is the echo name a common pattern / term for such a copy-in-to-out? I think Mule has a similar component also. So it might not be to bad to introduce. Maybe it will be obsolete if the camel components is smarter / more strict about the MEP patterns the support/use. Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: Hadrian Zbarcea [mailto:[EMAIL PROTECTED] Sent: 21. august 2008 18:32 To: [email protected] Subject: Re: echo() processor The DSL is big as it is. We add to it integration patterns, but my personal preference would be to not add things like echo(). I would more in favor of having it a (static) method that returns a processor, so one would use it like: from(...).process(echo()); My $0.02, Hadrian On Aug 21, 2008, at 10:49 AM, Fintan Bolton wrote: > > 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. >
