camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From snowbug <laji.in...@gmail.com>
Subject Re: Why does ExchangeHelper.prepareAggregation modify the in body?
Date Wed, 02 Sep 2009 03:22:19 GMT

I think it does not make sense because after this operation, I have no way to
get back my original IN message which might be critical for processing.

Say I have a exchange that I splitted, did some processing on each of the
splitted exchange (which is in the IN message of the exchange), and set the
OUT message after each of the processing on the splitted exchange. Now in my
aggregation, I want to merge the OUT messages based on the content of the
original IN message. With this implementation, you simply can't do it
because the you don' t have the original IN message anymore. 

I understand you can check hasOut(). But the real problem here is that the
implementation clears the original IN message and it is a destructive
operation that can not be reversed!

At least it should provide a way to disable this behavior.

Alan



willem.jiang wrote:
> 
> Please use hasOut() to check if the out message is there.
> As the comments said, the prepareAggregation is make the user 
> aggregation strategy more easy, it just need to check the in message and 
> do not care about the out message.
> 
> Willem
> 
> snowbug wrote:
>> When doing aggregation, this code is executed before the actual
>> aggregation:
>>     /**
>>      * Prepares the exchanges for aggregation.
>>      * <p/>
>>      * This implementation will copy the OUT body to the IN body so when
>> you
>> do
>>      * aggregation the body is only in the IN body to avoid confusing end
>> users.
>>      *
>>      * @param oldExchange  the old exchange
>>      * @param newExchange  the new exchange
>>      */
>>     public static void prepareAggregation(Exchange oldExchange, Exchange
>> newExchange) {
>>         // copy body/header from OUT to IN
>>         if (oldExchange != null) {
>>             if (oldExchange.hasOut()) {
>>                 oldExchange.getIn().copyFrom(oldExchange.getOut());
>>                 oldExchange.setOut(null);
>>             }
>>         }
>> 
>>         if (newExchange != null) {
>>             if (newExchange.hasOut()) {
>>                 newExchange.getIn().copyFrom(newExchange.getOut());
>>                 newExchange.setOut(null);
>>             }
>>         }
>>     }
>> 
>> 
>> I have hard time to understand why the IN is overwritten automatically.
>> IN
>> is the message that comes in and should only be overwritten if I choose
>> to
>> based on my business logic, not have the framework code to assume this
>> behavior. 
>> 
>> To make the matter worse, the DefaultExchange.getOut() will automatically
>> create an empty Message when it is invoked. In other words, if
>> DefaultExchange.getOut() is called somewhere either in your code or
>> Camel's
>> code, the OUT message is automatically created, and the hasOut() method
>> will
>> then be true, and this default empty OUT message is then automatically
>> copied to the IN. 
>> 
>> If there is a compelling reason shows this behavior is absolutely
>> necessary,
>> I'd like to create a bug ticket to have it fixed.
>> 
>> Thanks,
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Why-does-ExchangeHelper.prepareAggregation-modify-the-in-body--tp25249162p25251098.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message