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:
>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);
>>
>>
>>
>>
>>
>>
>
>
>
>
