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
