A confusing things. pipeline's bug? or Processor's bug?

[ext2 <xu...@tongtech.com>]

Hi:
The mail tell 3 things: 
1) pipeline processor, along with other build-in processor of camel(which doesn't care MEP) will cause a confusing things;

2) some source code of camel concerned of this confusing.
3) how to understand the confusing things? it concerns of MEP , which has been discussed again and again. Sometimes I think I understand it, Sometimes it will confuse me again suddenly;

1)a confusing things of a simple test case:

from("direct:start2")
.multicast(new AggregateBean())
  .pipeline().transform(constant(1)).bean(new IncreaseBean()).end()
  .pipeline().transform(constant(1)).bean(new IncreaseBean()).end()
.end()
.to("mock:result2");

the two pipeline of multicast does same things: 1+1 = 2; and the multicast's aggregate will sum the two pipeline's result: that's 2+2 = 4;
 
So the reasonable result of the route should be 4, but  the final result is 2 when using the default MEP(inOnly);

Is it a bug? How could camel to resolve it ?

2) source code concerned with this confuse things

2.1): TransformProcess's source code, it always set output , which doesn't obey rule's of camel MEP;
	Object newBody = expression.evaluate(exchange, Object.class);
	exchange.getOut().setBody(newBody);


2.2): source code from pipeline:
  if (first) {
  	first = false;//so the first processor of pipeline will directly change the exchange.
  } else {
     // prepare for next run
     nextExchange = createNextExchange(nextExchange);
  }

the first processor of pipeline will directly change the exchange instance received by pipeline. 

2.3): source code of PipeLine:
 ExchangeHelper.copyResults(exchange, nextExchange);
Here, var "exchange" is the original exchange, "nextExchange" will be the last processor's result;
So at the end of pipeline's process, the original exchange will be used to calculate the result of pipeline;
 Because if the MEP is inOnly , so the bean's result (integer 2) will set to the in message.But the first processor of pipeline is transform, and it also directly set out message; so the final result of pipeline is : exchange{in=2, out=1};
Then the multicast processor is confused, it thinks the out message contains the result(but actually in message contains), so the aggregate will receive the number 1(not number 2) as input to sum;

3) confuse things about the problem.
Now the reason of the confusing is clearly, but how to correct it?
It's TransformProcessor's question , PipeLine's question

At first I think it's the TransformProcessor's question, because it doesn't obey the rule of camel MEP: it should check MEP and return result in out or in message;

But let's check the source code of Pipeline: 1) in the pipeline, no matter which MEP is, it always assume out message prior to in message. So if out message exist ,pipeline will always using the out as next processor's input  2) No matter what MEP is, if the last processor 's exchange has out, the pipeline processor will use it's out message as result;

Now a conflict thing occurred: 
1)If camel ask for all processor shouldn't return out message in INONLY MEP, why the camel itself process the Out message in InOnly mep?  
Why not just raise a fatal error to say the process shouldn't return out message in InOnly MEP.

2) if camel allow some processor could return the out message in InOnly MEP for some special purpose, so what's the special purpose, how to understand it?