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

Reply via email to