Hi I have created a JIRA ticket https://issues.apache.org/jira/browse/CAMEL-4033
On Sat, May 28, 2011 at 3:25 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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/ > -- 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/
