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.mcf...@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 <dwhyt...@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.mcf...@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 <dwhyt...@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.mcf...@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
>> >> >
>> >>
>> >
>>
>
