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 > >> > > >> > > >
