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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> > >> 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 < > [email protected] > >> > > >> >> 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 > >> >> > > >> >> > >> > > >> > > >
