I just tried it. Sadly, the inOnly() trick does not work. On Fri, May 27, 2011 at 5:50 PM, Donald Whytock <dwhyt...@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 <gregory.mcf...@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 <dwhyt...@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.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 > >> >> >> > > >> >> >> > >> >> > > >> >> > >> > > >> > > >