You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Greg McFall <gr...@gmail.com> on 2011/05/27 18:36:43 UTC
Loop usage
Hi,
The Camel documentation contains the following statement about the Loop
pattern:
The Loop allows to process a message a number of times and possibly process
them in a different way.
This seems to imply that the same input message will be processed by the
downstream pipeline with each subsequent iteration.
But my experience shows that the output from one iteration of the loop is
used as input to the next iteration.
Is this the expected behavior?
That seems like a strange way to define a loop.
Is there any way to coerce the Loop to operate on the same exact input
message for each iteration?
Cheers,
Greg McFall
Re: Loop usage
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have created a JIRA ticket
https://issues.apache.org/jira/browse/CAMEL-4033
On Sat, May 28, 2011 at 3:25 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Fell free to create a JIRA ticket for an improvement to the loop DSL
> so we can add an option to control if looping should be from
> - a copy of the input message
> - continue looping the same message
>
> http://camel.apache.org/support
>
> On Fri, May 27, 2011 at 11:58 PM, Greg McFall <gr...@gmail.com> wrote:
>> I just tried it. Sadly, the inOnly() trick does not work.
>>
>> On Fri, May 27, 2011 at 5:50 PM, Donald Whytock <dw...@gmail.com> wrote:
>>
>>> Have you tried using inOnly()? As in
>>>
>>> from(start).loop(3).inOnly().to(endpoint);
>>>
>>> On Fri, May 27, 2011 at 5:34 PM, Greg McFall <gr...@gmail.com>
>>> wrote:
>>> > Don,
>>> > If the LoopProcessor was intentionally designed so that the output from
>>> one
>>> > iteration is used as input to the next iteration, then the documentation
>>> > should say so.
>>> > The current documentation is misleading because it implies a different
>>> > behavior. It implies that the original message is repeated for each
>>> > iteration of the loop.
>>> >
>>> > Even if it is not a bug, I think there is a case for an enhancement
>>> request.
>>> > There ought to be an option to process the same message multiple times
>>> > instead of using the output from one iteration as input to the next
>>> > iteration.
>>> >
>>> > For example, I'd like to be able to do something like the following:
>>> >
>>> > from(start).loop(3).repeatOriginalMessage().to(endpoint);
>>> >
>>> > ~ Greg
>>> >
>>> >
>>> >
>>> > On Fri, May 27, 2011 at 5:16 PM, Donald Whytock <dw...@gmail.com>
>>> wrote:
>>> >
>>> >> 1. The CopyProcessor, yes, that doesn't currently exist. The
>>> >> processor to hand to the CopyProcessor should be whatever you're using
>>> >> already. If you're just sending the message to an endpoint over and
>>> >> over, it could be an instance of SendProcessor(endpoint).
>>> >>
>>> >> 2. I don't think it's a bug. A given Processor is inherently a
>>> >> transformer; I could see a situation where you'd want to modify the
>>> >> same exchange over and over. So the functionality of the loop is
>>> >> entirely dependent on the functionality of the processor you attach to
>>> >> it.
>>> >>
>>> >> On Fri, May 27, 2011 at 4:48 PM, Greg McFall <gr...@gmail.com>
>>> >> wrote:
>>> >> > Don,
>>> >> >
>>> >> > Yes, that might work. But I have two issues:
>>> >> >
>>> >> > 1. This solution requires that I somehow build the downstream
>>> Processor
>>> >> > that I will pass as an argument to the constructor. This is certainly
>>> >> > possible, but it does not mesh well with the fluid Java DSL.
>>> >> >
>>> >> > 2. It seems to me that I should not have to resort to a workaround
>>> like
>>> >> the
>>> >> > one you proposed. I am wondering if this is bug in the LoopProcessor
>>> >> > implementation that should be reported. (Or maybe it's a bug in the
>>> >> > documentation.)
>>> >> >
>>> >> > ~ Greg
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> >> Create a CopyProcessor, along the lines of:
>>> >> >>
>>> >> >> public class CopyProcessor implements Processor
>>> >> >> {
>>> >> >> Processor processor;
>>> >> >>
>>> >> >> public CopyProcessor(Processor processor)
>>> >> >> { this.processor = processor; }
>>> >> >>
>>> >> >> public void process(Exchange exchange) throws Exception
>>> >> >> { processor.process(exchange.copy()); }
>>> >> >>
>>> >> >> }
>>> >> >>
>>> >> >> Then use it in your loop:
>>> >> >>
>>> >> >> from(endpoint)
>>> >> >> .process(new LoopProcessor(new CopyProcessor(processor)));
>>> >> >>
>>> >> >> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <
>>> gregory.mcfall@gmail.com>
>>> >> >> wrote:
>>> >> >> > Don,
>>> >> >> >
>>> >> >> > I don't understand what you are proposing. How would I swap out
>>> the
>>> >> >> > exchange?
>>> >> >> >
>>> >> >> > ~ Greg
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <
>>> dwhytock@gmail.com>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >> How about using Exchange.copy() to pass a copy of the exchange to
>>> the
>>> >> >> >> downstream processor, so that the original exchange doesn't get
>>> >> >> >> changed?
>>> >> >> >>
>>> >> >> >> Don
>>> >> >> >>
>>> >> >> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <
>>> >> gregory.mcfall@gmail.com
>>> >> >> >
>>> >> >> >> wrote:
>>> >> >> >> > Hi,
>>> >> >> >> >
>>> >> >> >> > The Camel documentation contains the following statement about
>>> the
>>> >> >> Loop
>>> >> >> >> > pattern:
>>> >> >> >> >
>>> >> >> >> > The Loop allows to process a message a number of times and
>>> possibly
>>> >> >> >> process
>>> >> >> >> > them in a different way.
>>> >> >> >> >
>>> >> >> >> > This seems to imply that the same input message will be
>>> processed
>>> >> by
>>> >> >> the
>>> >> >> >> > downstream pipeline with each subsequent iteration.
>>> >> >> >> > But my experience shows that the output from one iteration of
>>> the
>>> >> loop
>>> >> >> is
>>> >> >> >> > used as input to the next iteration.
>>> >> >> >> >
>>> >> >> >> > Is this the expected behavior?
>>> >> >> >> > That seems like a strange way to define a loop.
>>> >> >> >> > Is there any way to coerce the Loop to operate on the same exact
>>> >> input
>>> >> >> >> > message for each iteration?
>>> >> >> >> >
>>> >> >> >> > Cheers,
>>> >> >> >> > Greg McFall
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >
>>> >>
>>> >
>>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> CamelOne 2011: http://fusesource.com/camelone2011/
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Loop usage
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Fell free to create a JIRA ticket for an improvement to the loop DSL
so we can add an option to control if looping should be from
- a copy of the input message
- continue looping the same message
http://camel.apache.org/support
On Fri, May 27, 2011 at 11:58 PM, Greg McFall <gr...@gmail.com> wrote:
> I just tried it. Sadly, the inOnly() trick does not work.
>
> On Fri, May 27, 2011 at 5:50 PM, Donald Whytock <dw...@gmail.com> wrote:
>
>> Have you tried using inOnly()? As in
>>
>> from(start).loop(3).inOnly().to(endpoint);
>>
>> On Fri, May 27, 2011 at 5:34 PM, Greg McFall <gr...@gmail.com>
>> wrote:
>> > Don,
>> > If the LoopProcessor was intentionally designed so that the output from
>> one
>> > iteration is used as input to the next iteration, then the documentation
>> > should say so.
>> > The current documentation is misleading because it implies a different
>> > behavior. It implies that the original message is repeated for each
>> > iteration of the loop.
>> >
>> > Even if it is not a bug, I think there is a case for an enhancement
>> request.
>> > There ought to be an option to process the same message multiple times
>> > instead of using the output from one iteration as input to the next
>> > iteration.
>> >
>> > For example, I'd like to be able to do something like the following:
>> >
>> > from(start).loop(3).repeatOriginalMessage().to(endpoint);
>> >
>> > ~ Greg
>> >
>> >
>> >
>> > On Fri, May 27, 2011 at 5:16 PM, Donald Whytock <dw...@gmail.com>
>> wrote:
>> >
>> >> 1. The CopyProcessor, yes, that doesn't currently exist. The
>> >> processor to hand to the CopyProcessor should be whatever you're using
>> >> already. If you're just sending the message to an endpoint over and
>> >> over, it could be an instance of SendProcessor(endpoint).
>> >>
>> >> 2. I don't think it's a bug. A given Processor is inherently a
>> >> transformer; I could see a situation where you'd want to modify the
>> >> same exchange over and over. So the functionality of the loop is
>> >> entirely dependent on the functionality of the processor you attach to
>> >> it.
>> >>
>> >> On Fri, May 27, 2011 at 4:48 PM, Greg McFall <gr...@gmail.com>
>> >> wrote:
>> >> > Don,
>> >> >
>> >> > Yes, that might work. But I have two issues:
>> >> >
>> >> > 1. This solution requires that I somehow build the downstream
>> Processor
>> >> > that I will pass as an argument to the constructor. This is certainly
>> >> > possible, but it does not mesh well with the fluid Java DSL.
>> >> >
>> >> > 2. It seems to me that I should not have to resort to a workaround
>> like
>> >> the
>> >> > one you proposed. I am wondering if this is bug in the LoopProcessor
>> >> > implementation that should be reported. (Or maybe it's a bug in the
>> >> > documentation.)
>> >> >
>> >> > ~ Greg
>> >> >
>> >> >
>> >> >
>> >> > On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> Create a CopyProcessor, along the lines of:
>> >> >>
>> >> >> public class CopyProcessor implements Processor
>> >> >> {
>> >> >> Processor processor;
>> >> >>
>> >> >> public CopyProcessor(Processor processor)
>> >> >> { this.processor = processor; }
>> >> >>
>> >> >> public void process(Exchange exchange) throws Exception
>> >> >> { processor.process(exchange.copy()); }
>> >> >>
>> >> >> }
>> >> >>
>> >> >> Then use it in your loop:
>> >> >>
>> >> >> from(endpoint)
>> >> >> .process(new LoopProcessor(new CopyProcessor(processor)));
>> >> >>
>> >> >> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <
>> gregory.mcfall@gmail.com>
>> >> >> wrote:
>> >> >> > Don,
>> >> >> >
>> >> >> > I don't understand what you are proposing. How would I swap out
>> the
>> >> >> > exchange?
>> >> >> >
>> >> >> > ~ Greg
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <
>> dwhytock@gmail.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >> How about using Exchange.copy() to pass a copy of the exchange to
>> the
>> >> >> >> downstream processor, so that the original exchange doesn't get
>> >> >> >> changed?
>> >> >> >>
>> >> >> >> Don
>> >> >> >>
>> >> >> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <
>> >> gregory.mcfall@gmail.com
>> >> >> >
>> >> >> >> wrote:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > The Camel documentation contains the following statement about
>> the
>> >> >> Loop
>> >> >> >> > pattern:
>> >> >> >> >
>> >> >> >> > The Loop allows to process a message a number of times and
>> possibly
>> >> >> >> process
>> >> >> >> > them in a different way.
>> >> >> >> >
>> >> >> >> > This seems to imply that the same input message will be
>> processed
>> >> by
>> >> >> the
>> >> >> >> > downstream pipeline with each subsequent iteration.
>> >> >> >> > But my experience shows that the output from one iteration of
>> the
>> >> loop
>> >> >> is
>> >> >> >> > used as input to the next iteration.
>> >> >> >> >
>> >> >> >> > Is this the expected behavior?
>> >> >> >> > That seems like a strange way to define a loop.
>> >> >> >> > Is there any way to coerce the Loop to operate on the same exact
>> >> input
>> >> >> >> > message for each iteration?
>> >> >> >> >
>> >> >> >> > Cheers,
>> >> >> >> > Greg McFall
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Loop usage
Posted by Greg McFall <gr...@gmail.com>.
I just tried it. Sadly, the inOnly() trick does not work.
On Fri, May 27, 2011 at 5:50 PM, Donald Whytock <dw...@gmail.com> wrote:
> Have you tried using inOnly()? As in
>
> from(start).loop(3).inOnly().to(endpoint);
>
> On Fri, May 27, 2011 at 5:34 PM, Greg McFall <gr...@gmail.com>
> wrote:
> > Don,
> > If the LoopProcessor was intentionally designed so that the output from
> one
> > iteration is used as input to the next iteration, then the documentation
> > should say so.
> > The current documentation is misleading because it implies a different
> > behavior. It implies that the original message is repeated for each
> > iteration of the loop.
> >
> > Even if it is not a bug, I think there is a case for an enhancement
> request.
> > There ought to be an option to process the same message multiple times
> > instead of using the output from one iteration as input to the next
> > iteration.
> >
> > For example, I'd like to be able to do something like the following:
> >
> > from(start).loop(3).repeatOriginalMessage().to(endpoint);
> >
> > ~ Greg
> >
> >
> >
> > On Fri, May 27, 2011 at 5:16 PM, Donald Whytock <dw...@gmail.com>
> wrote:
> >
> >> 1. The CopyProcessor, yes, that doesn't currently exist. The
> >> processor to hand to the CopyProcessor should be whatever you're using
> >> already. If you're just sending the message to an endpoint over and
> >> over, it could be an instance of SendProcessor(endpoint).
> >>
> >> 2. I don't think it's a bug. A given Processor is inherently a
> >> transformer; I could see a situation where you'd want to modify the
> >> same exchange over and over. So the functionality of the loop is
> >> entirely dependent on the functionality of the processor you attach to
> >> it.
> >>
> >> On Fri, May 27, 2011 at 4:48 PM, Greg McFall <gr...@gmail.com>
> >> wrote:
> >> > Don,
> >> >
> >> > Yes, that might work. But I have two issues:
> >> >
> >> > 1. This solution requires that I somehow build the downstream
> Processor
> >> > that I will pass as an argument to the constructor. This is certainly
> >> > possible, but it does not mesh well with the fluid Java DSL.
> >> >
> >> > 2. It seems to me that I should not have to resort to a workaround
> like
> >> the
> >> > one you proposed. I am wondering if this is bug in the LoopProcessor
> >> > implementation that should be reported. (Or maybe it's a bug in the
> >> > documentation.)
> >> >
> >> > ~ Greg
> >> >
> >> >
> >> >
> >> > On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com>
> >> wrote:
> >> >
> >> >> Create a CopyProcessor, along the lines of:
> >> >>
> >> >> public class CopyProcessor implements Processor
> >> >> {
> >> >> Processor processor;
> >> >>
> >> >> public CopyProcessor(Processor processor)
> >> >> { this.processor = processor; }
> >> >>
> >> >> public void process(Exchange exchange) throws Exception
> >> >> { processor.process(exchange.copy()); }
> >> >>
> >> >> }
> >> >>
> >> >> Then use it in your loop:
> >> >>
> >> >> from(endpoint)
> >> >> .process(new LoopProcessor(new CopyProcessor(processor)));
> >> >>
> >> >> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <
> gregory.mcfall@gmail.com>
> >> >> wrote:
> >> >> > Don,
> >> >> >
> >> >> > I don't understand what you are proposing. How would I swap out
> the
> >> >> > exchange?
> >> >> >
> >> >> > ~ Greg
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <
> dwhytock@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> >> How about using Exchange.copy() to pass a copy of the exchange to
> the
> >> >> >> downstream processor, so that the original exchange doesn't get
> >> >> >> changed?
> >> >> >>
> >> >> >> Don
> >> >> >>
> >> >> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <
> >> gregory.mcfall@gmail.com
> >> >> >
> >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > The Camel documentation contains the following statement about
> the
> >> >> Loop
> >> >> >> > pattern:
> >> >> >> >
> >> >> >> > The Loop allows to process a message a number of times and
> possibly
> >> >> >> process
> >> >> >> > them in a different way.
> >> >> >> >
> >> >> >> > This seems to imply that the same input message will be
> processed
> >> by
> >> >> the
> >> >> >> > downstream pipeline with each subsequent iteration.
> >> >> >> > But my experience shows that the output from one iteration of
> the
> >> loop
> >> >> is
> >> >> >> > used as input to the next iteration.
> >> >> >> >
> >> >> >> > Is this the expected behavior?
> >> >> >> > That seems like a strange way to define a loop.
> >> >> >> > Is there any way to coerce the Loop to operate on the same exact
> >> input
> >> >> >> > message for each iteration?
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Greg McFall
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: Loop usage
Posted by Donald Whytock <dw...@gmail.com>.
Have you tried using inOnly()? As in
from(start).loop(3).inOnly().to(endpoint);
On Fri, May 27, 2011 at 5:34 PM, Greg McFall <gr...@gmail.com> wrote:
> Don,
> If the LoopProcessor was intentionally designed so that the output from one
> iteration is used as input to the next iteration, then the documentation
> should say so.
> The current documentation is misleading because it implies a different
> behavior. It implies that the original message is repeated for each
> iteration of the loop.
>
> Even if it is not a bug, I think there is a case for an enhancement request.
> There ought to be an option to process the same message multiple times
> instead of using the output from one iteration as input to the next
> iteration.
>
> For example, I'd like to be able to do something like the following:
>
> from(start).loop(3).repeatOriginalMessage().to(endpoint);
>
> ~ Greg
>
>
>
> On Fri, May 27, 2011 at 5:16 PM, Donald Whytock <dw...@gmail.com> wrote:
>
>> 1. The CopyProcessor, yes, that doesn't currently exist. The
>> processor to hand to the CopyProcessor should be whatever you're using
>> already. If you're just sending the message to an endpoint over and
>> over, it could be an instance of SendProcessor(endpoint).
>>
>> 2. I don't think it's a bug. A given Processor is inherently a
>> transformer; I could see a situation where you'd want to modify the
>> same exchange over and over. So the functionality of the loop is
>> entirely dependent on the functionality of the processor you attach to
>> it.
>>
>> On Fri, May 27, 2011 at 4:48 PM, Greg McFall <gr...@gmail.com>
>> wrote:
>> > Don,
>> >
>> > Yes, that might work. But I have two issues:
>> >
>> > 1. This solution requires that I somehow build the downstream Processor
>> > that I will pass as an argument to the constructor. This is certainly
>> > possible, but it does not mesh well with the fluid Java DSL.
>> >
>> > 2. It seems to me that I should not have to resort to a workaround like
>> the
>> > one you proposed. I am wondering if this is bug in the LoopProcessor
>> > implementation that should be reported. (Or maybe it's a bug in the
>> > documentation.)
>> >
>> > ~ Greg
>> >
>> >
>> >
>> > On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com>
>> wrote:
>> >
>> >> Create a CopyProcessor, along the lines of:
>> >>
>> >> public class CopyProcessor implements Processor
>> >> {
>> >> Processor processor;
>> >>
>> >> public CopyProcessor(Processor processor)
>> >> { this.processor = processor; }
>> >>
>> >> public void process(Exchange exchange) throws Exception
>> >> { processor.process(exchange.copy()); }
>> >>
>> >> }
>> >>
>> >> Then use it in your loop:
>> >>
>> >> from(endpoint)
>> >> .process(new LoopProcessor(new CopyProcessor(processor)));
>> >>
>> >> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <gr...@gmail.com>
>> >> wrote:
>> >> > Don,
>> >> >
>> >> > I don't understand what you are proposing. How would I swap out the
>> >> > exchange?
>> >> >
>> >> > ~ Greg
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <dw...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> How about using Exchange.copy() to pass a copy of the exchange to the
>> >> >> downstream processor, so that the original exchange doesn't get
>> >> >> changed?
>> >> >>
>> >> >> Don
>> >> >>
>> >> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <
>> gregory.mcfall@gmail.com
>> >> >
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > The Camel documentation contains the following statement about the
>> >> Loop
>> >> >> > pattern:
>> >> >> >
>> >> >> > The Loop allows to process a message a number of times and possibly
>> >> >> process
>> >> >> > them in a different way.
>> >> >> >
>> >> >> > This seems to imply that the same input message will be processed
>> by
>> >> the
>> >> >> > downstream pipeline with each subsequent iteration.
>> >> >> > But my experience shows that the output from one iteration of the
>> loop
>> >> is
>> >> >> > used as input to the next iteration.
>> >> >> >
>> >> >> > Is this the expected behavior?
>> >> >> > That seems like a strange way to define a loop.
>> >> >> > Is there any way to coerce the Loop to operate on the same exact
>> input
>> >> >> > message for each iteration?
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Greg McFall
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>
Re: Loop usage
Posted by Greg McFall <gr...@gmail.com>.
Don,
If the LoopProcessor was intentionally designed so that the output from one
iteration is used as input to the next iteration, then the documentation
should say so.
The current documentation is misleading because it implies a different
behavior. It implies that the original message is repeated for each
iteration of the loop.
Even if it is not a bug, I think there is a case for an enhancement request.
There ought to be an option to process the same message multiple times
instead of using the output from one iteration as input to the next
iteration.
For example, I'd like to be able to do something like the following:
from(start).loop(3).repeatOriginalMessage().to(endpoint);
~ Greg
On Fri, May 27, 2011 at 5:16 PM, Donald Whytock <dw...@gmail.com> wrote:
> 1. The CopyProcessor, yes, that doesn't currently exist. The
> processor to hand to the CopyProcessor should be whatever you're using
> already. If you're just sending the message to an endpoint over and
> over, it could be an instance of SendProcessor(endpoint).
>
> 2. I don't think it's a bug. A given Processor is inherently a
> transformer; I could see a situation where you'd want to modify the
> same exchange over and over. So the functionality of the loop is
> entirely dependent on the functionality of the processor you attach to
> it.
>
> On Fri, May 27, 2011 at 4:48 PM, Greg McFall <gr...@gmail.com>
> wrote:
> > Don,
> >
> > Yes, that might work. But I have two issues:
> >
> > 1. This solution requires that I somehow build the downstream Processor
> > that I will pass as an argument to the constructor. This is certainly
> > possible, but it does not mesh well with the fluid Java DSL.
> >
> > 2. It seems to me that I should not have to resort to a workaround like
> the
> > one you proposed. I am wondering if this is bug in the LoopProcessor
> > implementation that should be reported. (Or maybe it's a bug in the
> > documentation.)
> >
> > ~ Greg
> >
> >
> >
> > On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com>
> wrote:
> >
> >> Create a CopyProcessor, along the lines of:
> >>
> >> public class CopyProcessor implements Processor
> >> {
> >> Processor processor;
> >>
> >> public CopyProcessor(Processor processor)
> >> { this.processor = processor; }
> >>
> >> public void process(Exchange exchange) throws Exception
> >> { processor.process(exchange.copy()); }
> >>
> >> }
> >>
> >> Then use it in your loop:
> >>
> >> from(endpoint)
> >> .process(new LoopProcessor(new CopyProcessor(processor)));
> >>
> >> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <gr...@gmail.com>
> >> wrote:
> >> > Don,
> >> >
> >> > I don't understand what you are proposing. How would I swap out the
> >> > exchange?
> >> >
> >> > ~ Greg
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <dw...@gmail.com>
> >> wrote:
> >> >
> >> >> How about using Exchange.copy() to pass a copy of the exchange to the
> >> >> downstream processor, so that the original exchange doesn't get
> >> >> changed?
> >> >>
> >> >> Don
> >> >>
> >> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <
> gregory.mcfall@gmail.com
> >> >
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > The Camel documentation contains the following statement about the
> >> Loop
> >> >> > pattern:
> >> >> >
> >> >> > The Loop allows to process a message a number of times and possibly
> >> >> process
> >> >> > them in a different way.
> >> >> >
> >> >> > This seems to imply that the same input message will be processed
> by
> >> the
> >> >> > downstream pipeline with each subsequent iteration.
> >> >> > But my experience shows that the output from one iteration of the
> loop
> >> is
> >> >> > used as input to the next iteration.
> >> >> >
> >> >> > Is this the expected behavior?
> >> >> > That seems like a strange way to define a loop.
> >> >> > Is there any way to coerce the Loop to operate on the same exact
> input
> >> >> > message for each iteration?
> >> >> >
> >> >> > Cheers,
> >> >> > Greg McFall
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: Loop usage
Posted by Donald Whytock <dw...@gmail.com>.
1. The CopyProcessor, yes, that doesn't currently exist. The
processor to hand to the CopyProcessor should be whatever you're using
already. If you're just sending the message to an endpoint over and
over, it could be an instance of SendProcessor(endpoint).
2. I don't think it's a bug. A given Processor is inherently a
transformer; I could see a situation where you'd want to modify the
same exchange over and over. So the functionality of the loop is
entirely dependent on the functionality of the processor you attach to
it.
On Fri, May 27, 2011 at 4:48 PM, Greg McFall <gr...@gmail.com> wrote:
> Don,
>
> Yes, that might work. But I have two issues:
>
> 1. This solution requires that I somehow build the downstream Processor
> that I will pass as an argument to the constructor. This is certainly
> possible, but it does not mesh well with the fluid Java DSL.
>
> 2. It seems to me that I should not have to resort to a workaround like the
> one you proposed. I am wondering if this is bug in the LoopProcessor
> implementation that should be reported. (Or maybe it's a bug in the
> documentation.)
>
> ~ Greg
>
>
>
> On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com> wrote:
>
>> Create a CopyProcessor, along the lines of:
>>
>> public class CopyProcessor implements Processor
>> {
>> Processor processor;
>>
>> public CopyProcessor(Processor processor)
>> { this.processor = processor; }
>>
>> public void process(Exchange exchange) throws Exception
>> { processor.process(exchange.copy()); }
>>
>> }
>>
>> Then use it in your loop:
>>
>> from(endpoint)
>> .process(new LoopProcessor(new CopyProcessor(processor)));
>>
>> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <gr...@gmail.com>
>> wrote:
>> > Don,
>> >
>> > I don't understand what you are proposing. How would I swap out the
>> > exchange?
>> >
>> > ~ Greg
>> >
>> >
>> >
>> >
>> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <dw...@gmail.com>
>> wrote:
>> >
>> >> How about using Exchange.copy() to pass a copy of the exchange to the
>> >> downstream processor, so that the original exchange doesn't get
>> >> changed?
>> >>
>> >> Don
>> >>
>> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <gregory.mcfall@gmail.com
>> >
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > The Camel documentation contains the following statement about the
>> Loop
>> >> > pattern:
>> >> >
>> >> > The Loop allows to process a message a number of times and possibly
>> >> process
>> >> > them in a different way.
>> >> >
>> >> > This seems to imply that the same input message will be processed by
>> the
>> >> > downstream pipeline with each subsequent iteration.
>> >> > But my experience shows that the output from one iteration of the loop
>> is
>> >> > used as input to the next iteration.
>> >> >
>> >> > Is this the expected behavior?
>> >> > That seems like a strange way to define a loop.
>> >> > Is there any way to coerce the Loop to operate on the same exact input
>> >> > message for each iteration?
>> >> >
>> >> > Cheers,
>> >> > Greg McFall
>> >> >
>> >>
>> >
>>
>
Re: Loop usage
Posted by Greg McFall <gr...@gmail.com>.
Don,
Yes, that might work. But I have two issues:
1. This solution requires that I somehow build the downstream Processor
that I will pass as an argument to the constructor. This is certainly
possible, but it does not mesh well with the fluid Java DSL.
2. It seems to me that I should not have to resort to a workaround like the
one you proposed. I am wondering if this is bug in the LoopProcessor
implementation that should be reported. (Or maybe it's a bug in the
documentation.)
~ Greg
On Fri, May 27, 2011 at 1:58 PM, Donald Whytock <dw...@gmail.com> wrote:
> Create a CopyProcessor, along the lines of:
>
> public class CopyProcessor implements Processor
> {
> Processor processor;
>
> public CopyProcessor(Processor processor)
> { this.processor = processor; }
>
> public void process(Exchange exchange) throws Exception
> { processor.process(exchange.copy()); }
>
> }
>
> Then use it in your loop:
>
> from(endpoint)
> .process(new LoopProcessor(new CopyProcessor(processor)));
>
> On Fri, May 27, 2011 at 1:24 PM, Greg McFall <gr...@gmail.com>
> wrote:
> > Don,
> >
> > I don't understand what you are proposing. How would I swap out the
> > exchange?
> >
> > ~ Greg
> >
> >
> >
> >
> > On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <dw...@gmail.com>
> wrote:
> >
> >> How about using Exchange.copy() to pass a copy of the exchange to the
> >> downstream processor, so that the original exchange doesn't get
> >> changed?
> >>
> >> Don
> >>
> >> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <gregory.mcfall@gmail.com
> >
> >> wrote:
> >> > Hi,
> >> >
> >> > The Camel documentation contains the following statement about the
> Loop
> >> > pattern:
> >> >
> >> > The Loop allows to process a message a number of times and possibly
> >> process
> >> > them in a different way.
> >> >
> >> > This seems to imply that the same input message will be processed by
> the
> >> > downstream pipeline with each subsequent iteration.
> >> > But my experience shows that the output from one iteration of the loop
> is
> >> > used as input to the next iteration.
> >> >
> >> > Is this the expected behavior?
> >> > That seems like a strange way to define a loop.
> >> > Is there any way to coerce the Loop to operate on the same exact input
> >> > message for each iteration?
> >> >
> >> > Cheers,
> >> > Greg McFall
> >> >
> >>
> >
>
Re: Loop usage
Posted by Donald Whytock <dw...@gmail.com>.
Create a CopyProcessor, along the lines of:
public class CopyProcessor implements Processor
{
Processor processor;
public CopyProcessor(Processor processor)
{ this.processor = processor; }
public void process(Exchange exchange) throws Exception
{ processor.process(exchange.copy()); }
}
Then use it in your loop:
from(endpoint)
.process(new LoopProcessor(new CopyProcessor(processor)));
On Fri, May 27, 2011 at 1:24 PM, Greg McFall <gr...@gmail.com> wrote:
> Don,
>
> I don't understand what you are proposing. How would I swap out the
> exchange?
>
> ~ Greg
>
>
>
>
> On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <dw...@gmail.com> wrote:
>
>> How about using Exchange.copy() to pass a copy of the exchange to the
>> downstream processor, so that the original exchange doesn't get
>> changed?
>>
>> Don
>>
>> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <gr...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > The Camel documentation contains the following statement about the Loop
>> > pattern:
>> >
>> > The Loop allows to process a message a number of times and possibly
>> process
>> > them in a different way.
>> >
>> > This seems to imply that the same input message will be processed by the
>> > downstream pipeline with each subsequent iteration.
>> > But my experience shows that the output from one iteration of the loop is
>> > used as input to the next iteration.
>> >
>> > Is this the expected behavior?
>> > That seems like a strange way to define a loop.
>> > Is there any way to coerce the Loop to operate on the same exact input
>> > message for each iteration?
>> >
>> > Cheers,
>> > Greg McFall
>> >
>>
>
Re: Loop usage
Posted by Greg McFall <gr...@gmail.com>.
Don,
I don't understand what you are proposing. How would I swap out the
exchange?
~ Greg
On Fri, May 27, 2011 at 12:54 PM, Donald Whytock <dw...@gmail.com> wrote:
> How about using Exchange.copy() to pass a copy of the exchange to the
> downstream processor, so that the original exchange doesn't get
> changed?
>
> Don
>
> On Fri, May 27, 2011 at 12:36 PM, Greg McFall <gr...@gmail.com>
> wrote:
> > Hi,
> >
> > The Camel documentation contains the following statement about the Loop
> > pattern:
> >
> > The Loop allows to process a message a number of times and possibly
> process
> > them in a different way.
> >
> > This seems to imply that the same input message will be processed by the
> > downstream pipeline with each subsequent iteration.
> > But my experience shows that the output from one iteration of the loop is
> > used as input to the next iteration.
> >
> > Is this the expected behavior?
> > That seems like a strange way to define a loop.
> > Is there any way to coerce the Loop to operate on the same exact input
> > message for each iteration?
> >
> > Cheers,
> > Greg McFall
> >
>
Re: Loop usage
Posted by Donald Whytock <dw...@gmail.com>.
How about using Exchange.copy() to pass a copy of the exchange to the
downstream processor, so that the original exchange doesn't get
changed?
Don
On Fri, May 27, 2011 at 12:36 PM, Greg McFall <gr...@gmail.com> wrote:
> Hi,
>
> The Camel documentation contains the following statement about the Loop
> pattern:
>
> The Loop allows to process a message a number of times and possibly process
> them in a different way.
>
> This seems to imply that the same input message will be processed by the
> downstream pipeline with each subsequent iteration.
> But my experience shows that the output from one iteration of the loop is
> used as input to the next iteration.
>
> Is this the expected behavior?
> That seems like a strange way to define a loop.
> Is there any way to coerce the Loop to operate on the same exact input
> message for each iteration?
>
> Cheers,
> Greg McFall
>