Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of gert.vanthienen@skynet.be
 designates 195.238.6.175 as permitted sender)
Message-ID: <4875CAB0.2030802@skynet.be>
Date: Thu, 10 Jul 2008 10:39:12 +0200
From: Gert Vanthienen <gert.vanthienen@skynet.be>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: camel-dev@activemq.apache.org
Subject: ExchangePattern handling in Camel
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

L.S.,

If you look at the comments on CAMEL-688 and some of the others mails on 
the commits, it looks like it is time we make up our minds what we want 
to do with ExchangePattern handling inside Camel.  Up to now, the 
ExchangePattern was there mostly for informational purposes -- e.g. to 
transfer this information inside Camel when interacting with JBI or CXF 
exchanges.

If it is just there for informational purposes however, we should try to 
avoid implementing other behavior based on the MEP.  For example: for 
CAMEL-688, we should follow on Claus' suggestion to just use 
getOut(true) to force the 'out' message to be created.

On the other hand, if we really want to honor the ExchangePattern inside 
Camel, the current patch is OK, but we probably also need a lot of other 
changes.  Just an example: the PipeLine currently sends the incoming 
exchange to the first target, even if this is an in-only exchange.  If 
we want to go for strict MEP handling, we should probably change that 
behavior so it always interacts with it targets in an in-out manner, 
allowing them to send set the 'out' message content.

As I said: I think it's time we make up our minds here, because the 
current situation is just a bit messy.  Personally, I would prefer to 
keep Camel as lightweight and simple as possible, just keeping the 
current behavior, where the MEP isn't influencing the behavior.

Regards,

Gert