The MEP is very important from outside camel. It tells camel if the producer (client) who send the request is waiting for a response or not. Thus it allows consumers to know what to do, but it is (almost) not relevant on the route itself. It looks like I should have clarified this better.
Cheers, Hadrian On Oct 14, 2010, at 1:54 AM, ext2 wrote: > 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 > sense? > >> I hope this helps, >> Hadrian > > >> 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 > or >> out message? I can only determine it by exchange pattern; >> If the route is using InOnly pattern(which is default), the aggregator > will >> 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] http://camelbot.blogspot.com/2010/10/should-you-getin-or-getout.html >> >> >> 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? >>> >>> >> >> >> > > >
