camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <dwhyt...@gmail.com>
Subject Re: Loop usage
Date Fri, 27 May 2011 21:50:42 GMT
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 <gregory.mcfall@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 <dwhytock@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 <gregory.mcfall@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 <dwhytock@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
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>

Mime
View raw message