camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: ExchangePattern handling in Camel
Date Thu, 10 Jul 2008 10:23:54 GMT

We are now using getOut(true) in the code.
Thanks for reporting it and trying Camel in OSGi platforms and integrated with ServiceMix.
Keep up the good work.

Med venlig hilsen
Claus Ibsen
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576

-----Original Message-----
From: Freeman Fang [] 
Sent: 10. juli 2008 12:17
Subject: Re: ExchangePattern handling in Camel

Hi Gert,

Use getOut(true) to force the 'out' message to be created sounds good to 
me as well, this would avoid introducing problem if I understand correctly


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

View raw message