Ok, good news I figured out what I should have been doing instead of a
RecipientList!
For giggles i was trying to route any message that had lower case letters in
it (just playing around)
So I finally discovered methodCall and simple. First i used methodCall to
call a matches method that returns
I still end up in the BeanProcessor using this technique and I get the same
results
As I said; the message DOES get routed to the recipient list; it's just the
result the ultimately winds it way back is the recipient list itself.
The more I think about it maybe that is the only behavior... a
On Thu, Feb 26, 2009 at 6:45 PM, paquettd wrote:
>
> Looking into this more it seems to be because I am ending up in a
> BeanProcessor. Line 120 of the bean processor is where the output of the
> @RecipientList method is overwriting the Out part of the exchange (which
> actually has the right data
Looking into this more it seems to be because I am ending up in a
BeanProcessor. Line 120 of the bean processor is where the output of the
@RecipientList method is overwriting the Out part of the exchange (which
actually has the right data in it at that point).
Using the Spring DSL is there a way
I'm seeing a behavior in camel 1.6 I don't understand. when I used the
producerTemplate to kickoff a workflow that
includes a @RecipientList component I seem to get back the result of the
recipient list... but my other services
end up being called (and their results simply lost to the ether).
Her
