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 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 inpu
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 wrote:
> I just tr
I just tried it. Sadly, the inOnly() trick does not work.
On Fri, May 27, 2011 at 5:50 PM, Donald Whytock 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
> wrote:
> > Don,
> > If the LoopProcessor wa
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 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
> s
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
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
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 hav
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()
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 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
> chan
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 wrote:
> Hi,
>
> The Camel documentation contains the following statement about the Loop
> pattern:
>
>
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 subsequ
11 matches
Mail list logo
