camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg McFall <gregory.mcf...@gmail.com>
Subject Re: Loop usage
Date Fri, 27 May 2011 21:58:11 GMT
I just tried it.  Sadly, the inOnly() trick does not work.

On Fri, May 27, 2011 at 5:50 PM, Donald Whytock <dwhytock@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.mcfall@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 <dwhytock@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.mcfall@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 <dwhytock@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.mcfall@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 <
> dwhytock@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.mcfall@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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message