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 willem.jiang@gmail.com
 designates 64.233.166.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=VNEA7RiZm8lsZ9onMMRehUq91HZ1r5syalZ9IFJwPdSDIMKn2Cf64hDB8HKSfKp4US
         AUk+fFAkU+7lawAJx7kcXHYI6Ars3VAfCOQPBtah1J20JJSx1Tjf8ltfZdc24kUt3j+Z
         drHwlseNtpsr49Q45qdNE9cGvVFaeqr0S9B0Y=
Message-ID: <4875D3A5.7090100@gmail.com>
Date: Thu, 10 Jul 2008 17:17:25 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: camel-dev@activemq.apache.org
Subject: Re: ExchangePattern handling in Camel
References: <4875CAB0.2030802@skynet.be>
In-Reply-To: <4875CAB0.2030802@skynet.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Gert,

In the default case (for handling JMS message), camel just use the 
ExchangePattern.InOnly,  so it is not surprise for use to see we can set 
the out message in a InOnly exchange.
But in camel-cxf component , we always want to camel's exchange working 
in InOut mode, because we need to set the response back.
I think current CAMEL-688 just add a restriction check for the exchange 
pattern, it cause some side effect on the BeanExpression which need to 
return the value even the exchange is InOnly.
I agree Gert's keeping the camel current behavior, because it simple for 
most case.

Willem

Gert Vanthienen wrote:
> 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
>