I know it, this is a my miss-understanding of camel's Processor; My work is not provide application for ending-user, but for another-develop-team to use. So the code of the processor cannot be full-controlled by my-self.
Anyway using Camel, I could extend to support the feature easily. This is camel's wonderful flexibility; Thanks a lot; -----origin----- Sender: Claus Ibsen [mailto:[email protected]] Date: 2010-1-16 20:05 Receiver: [email protected] Subject: Re: A bug of InOut pattern? On Sat, Jan 16, 2010 at 8:26 AM, ext2 <[email protected]> wrote: > This is a bad news for me. > > Processor is very useful for customized message transformer, but now it > seems the processor cannot provide MEP-independent feature. I must deal with > all the MEP of camel correctly in the Processor if I want to re-use the > processor in different MEP. > No you just need to store the transformation in the right place. Either at IN or OUT. Willem already showed you how to do that. And if you want a simple one liner then crete a static helper method and use it > Camel provide POJO Bean which provide MEP-independent feature. But it's not > very facility to customize message transformer at Message-Level. > > So, does the camel provide a processor which can work at Message-Level, and > provide MEP-independent feature? > > Maybe it would looks like: > > Interface MessageProcessor{ > Message process(Message msg); > } > > > > Willem Jiang wrote: >>Hi, > >>I think you processor should check the MEP for the exchange. >>As it broke the rule of MEP. >>Can you change the code like this, and run the test again? > >>Class IncreaseProcessor{ >> void process(Exchange me) >> { >> Integer result= me.getIn().getBody() + 1; >> if (me.getPattern().isOutCapable()) { >> me.getOut().setBody(result); >> } else { >> me.getIn().setBody(result); >> } >> } >> } >> > ext2 wrote: >> >> Yes you are right. >> But the real confusing thing is: the two routes I tested have same > semantic >> means, but the result is different. >> >> While I am try to find which caused the difference, I checked the source >> code of camel, and find a lot of camel-processor obey the following rule( > I >> thinks it's camel's default rule for MEP), but the pipe-line processor >> violate it (not same as the other processors): >> The rule is : >> 1)Processor will remember the input message-exchange >> 2)while the processor get the final result message-exchange, it will > combine >> the result message-exchange with the remembered input message-exchange. At >> this time, MEP will affect how to combine the two message-exchange >> 3) the combined result will act as the final result of processor; >> >> But the pipe-line processor doesn't remember the input message-exchange, > but >> remember the result of first processor in the pipe-line as the >> message-exchange to combine; So it cause the two routes has different >> result; >> >> >> Willem Jiang wrote: >>> Your processor should check the MEP, and don't set the out message if >>> the Exchange's MEP is InOnly. >> >>> If there is a out message, the pipeline will try to copy the out message >>> to next processor exchange's in message, otherwise it will copy the in >>> message to next processor exchange's in message. >> >>> Willem >> >> ext2 wrote: >>> Hi: >>> The camel 2.1's pipeline patter's MEP is InOnly default. But the result > of >>> following route is different, if I using inOnly() processor in route vs >>> using default; >>> >>> I tried it using a simple sample: send a message to a direct endpoint, >> which >>> body is number=1, a route receive the message and increase the message's >>> body twice by a processor, then send to a mock endpoint; >>> >>> The increase number process's code is: >>> >>> Class IncreaseProcessor{ >>> void process(MessageExchange me) >>> { >>> Integer result= Me.getIn().getBody() + 1; >>> Me.getOut().setBody(result); >>> } >>> } >>> >>> 1): following rout using inOnly() processor , and mock endpoint's return >>> ME's in.body=3, out=Null >>> >>> >> > from("direct:inOnlyUsingProcessor").inOnly().process(outProcessor).process(o >>> utProcessor).to("mock:result"); >>> >>> >>> 2) following route using default inOnly, and mock's return ME's > in.body=3, >>> out.body=2. >>> >> > from("direct:inOnlyDefault").process(outProcessor).process(outProcessor).to( >>> "mock:result"); >>> >>> So why the result has a out message and it's body=2, it should be same as >>> the first route(out=null); >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
