Hi Fell free to create a JIRA ticket for an improvement to the loop DSL so we can add an option to control if looping should be from - a copy of the input message - continue looping the same message
http://camel.apache.org/support On Fri, May 27, 2011 at 11:58 PM, Greg McFall <gregory.mcf...@gmail.com> wrote: > 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 >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com CamelOne 2011: http://fusesource.com/camelone2011/ Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
