You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Fintan Bolton <fi...@iona.com> on 2008/08/21 12:48:15 UTC
echo() processor
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.
Re: echo() processor
Posted by Hadrian Zbarcea <hz...@gmail.com>.
@Claus,
True. I guess using a bean in that case should be acceptable. It's
not 1-to-1 translation of the dsl, but should it be?
Hadrian
On Aug 22, 2008, at 6:19 AM, Fintan Bolton wrote:
>
> Hi Claus,
>
> If using a static method inside process(...), it might be clearer to
> give it
> a more explicit name. For example:
>
> from(...).process(copyInToOut());
>
> -
> Fintan
>
>
> -----Original Message-----
> 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:hzbarcea@gmail.com]
> Sent: 21. august 2008 18:32
> To: camel-user@activemq.apache.org
> 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
>
> --
> View this message in context: http://www.nabble.com/echo%28%29-processor-tp19086322s22882p19104719.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
RE: echo() processor
Posted by Fintan Bolton <fi...@iona.com>.
Hi Claus,
If using a static method inside process(...), it might be clearer to give it
a more explicit name. For example:
from(...).process(copyInToOut());
-
Fintan
-----Original Message-----
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:hzbarcea@gmail.com]
Sent: 21. august 2008 18:32
To: camel-user@activemq.apache.org
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
--
View this message in context: http://www.nabble.com/echo%28%29-processor-tp19086322s22882p19104719.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: echo() processor
Posted by Claus Ibsen <ci...@silverbullet.dk>.
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:hzbarcea@gmail.com]
Sent: 21. august 2008 18:32
To: camel-user@activemq.apache.org
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.
>
Re: echo() processor
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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.
>
Re: echo() processor
Posted by Fintan Bolton <fi...@iona.com>.
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.
Re: echo() processor
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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.
>