camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ext2" <>
Subject Re: A bug of InOut pattern?
Date Sat, 16 Jan 2010 07:26:01 GMT
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. 

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:

>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
> 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(
> 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
> 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,
> 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
>> 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
>> utProcessor).to("mock:result");
>> 2) following route using default inOnly, and mock's return ME's
>> out.body=2. 
>> "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);

View raw message