camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ext2" <>
Subject Re: TransformerProcessor doesn't deal with MEP( Why we need InOnly?)
Date Thu, 14 Oct 2010 05:54:19 GMT
Thanks a lot; 
Yes, you are right ;if output is present , it always means result, no matter
what the MEP is; 
But this confused my understanding about the exchange pattern;Why we need
the InOnly pattern?  Only for performance reason?  

If we has no such many patterns, event we didn't define the MEP for camel,
And we just determine the result by the out message exist or not. Things
will be more simply for the end-user;

If the performance is the only reason to introduce the InOnly pattern? If
so, it's not worth. 

Hadrian Zbarcea wrote:
>Then there's something wrong with the aggregator, I'd say.
>The result of processing is always: out if present, otherwise in. Makes

>I hope this helps,

>On Oct 14, 2010, at 12:43 AM, ext2 wrote:

> I still feel it's a bug; let's give a sample as following:
> <from uri="direct:start">
> <multicast ref="some-aggregate">
> 	<transform A/>
> 	<bean B/>
> 	<bean C/>
> <multicast>
> While writing the aggregator, how does I know where the result stored, in
> out message? I can only determine it by exchange pattern; 
> If the route is using InOnly pattern(which is default), the aggregator
> aggregate In message of Exchange. But the transform will always return out
> message as result, so the aggregate result isn't correct;
> ==============================================================
> Does this [1] explain it?
> Hadrian
> [1]
> On Oct 13, 2010, at 11:51 PM, ext2 wrote:
>> The Transformer Processor always  set Out Message as result and doesn't
>> care what MEP being;(At least until version camel 2.4.0, it being so,
> 2.5.0
>> I haven't checked)
>> It seems doesn't confirm to the rules of camel's MEP, why?

View raw message