>> Looking at the Camel code - Line 1165
>> <https://github.com/apache/camel/blob/master/camel-core/
>> src/main/java/org/apache/camel/model/ProcessorDefinition.java>
>> , that version of pipeline(String...uri) is simply a synonym for
>> to(String...uri), which would
master/camel-core/
> src/main/java/org/apache/camel/model/ProcessorDefinition.java>
> , that version of pipeline(String...uri) is simply a synonym for
> to(String...uri), which would explain how it is working.
>
> Someone else would need to speak to how it *ought* to work, but
pipeline(String...uri) is simply a synonym for
to(String...uri), which would explain how it is working.
Someone else would need to speak to how it *ought* to work, but I agree it
does not seem intuitive as-is.
--
View this message in context:
http://camel.465427.n5.nabble.com/Question-on-mul
TART
>>
>>
>> Best,
>> Edoardo
>>
>>> On 31 Oct 2016, at 15:04, DariusX wrote:
>>>
>>> Your example was:
>>> multicast()
>>> .pipeline("A", "B")
>>> .pipeline("C", "D&qu
t;.pipeline("A", "B")
> >.pipeline("C", "D")
> > .end()
> >
> > You send "START" as the body to this. So, you should expect "START" to be
> > the in.body for both "A" and "C".
>
quot;A" and "C".
>
> The in body for "B" will depend on what "A" does. Example: if "A" transforms
> the body to a constant "Hello from A", then that is what "B" will get as its
> in.body.
>
> Similarly, "D" will get whatever "C" decides to send along.
>
> If neither A nor C make any changes to the body, then you should expect
> "START" to be the in.body for all four.
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Question-on-multicast-to-pipelines-tp5789396p5789518.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
any changes to the body, then you should expect
"START" to be the in.body for all four.
--
View this message in context:
http://camel.465427.n5.nabble.com/Question-on-multicast-to-pipelines-tp5789396p5789518.html
Sent from the Camel - Users mailing list archive at Nabble.com.
"...yet they all fail (in the sense that they all receive the original
START incoming payload. Can anyone explain how this is expected behavior?"
All or just A and C receive the same message. I'd expect A and C to receive
the same message but not for B and D to (unless you don't change the
message
Hi Brad,
yes that's the definition of multicast but the documentation also suggests
that pipelines are supposed to be implicitly derived from a vararg to(...)
statement.
In any case I don't understand how the multicast could leak into a vararg
pipeline(...). It really feels like a bug to me, but
you want to
> multicast to send the message down both pipelines.
> But, that's probably not what you really want.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Question-on-multicast-to-pipelines-tp5789396p5789416.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
e down both pipelines.
> But, that's probably not what you really want.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Question-on-multicast-to-pipelines-tp5789396p5789416.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
el.465427.n5.nabble.com/Question-on-multicast-to-pipelines-tp5789396p5789416.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Hi all,
I had some trouble figuring out how to multicast to some pipelines. I
eventually found a [working] definition, but I also expected other forms to
work such as:
.multicast().aggregationStrategy(AggregationStrategies.groupedExchange())
.pipeline("A", "B")
.pipeline("C", "D")
.end(
13 matches
Mail list logo
