Hi Sergey,
i created a JIRA ( https://issues.apache.org/jira/browse/CAMEL-7061
<https://issues.apache.org/jira/browse/CAMEL-7061> ).
Sergey Beryozkin-3 wrote
> What I'm not understanding yet is what kind of response you actually get
> if IN message is checked ?
The problem in my case is that the last action of the TryProcessor is moving
the out message to the in message, thus setting the out message to null.
Now when the CxfRsInvokers returnResponse method is called, which populates
the response using the DefaultCxfRsBinding (calling
endpoint.getBinding().populateCxfRsResponseFromExchange(camelExchange,
cxfExchange))the exchange looks like:
Exchange
in : [MyPayload]
out : null
and the DefaultCxfRsBinding currently only uses the out message and if the
out message is null cxfrs returns the http response code 204.
When removing the <doTry> block the exchange that arrives at the
DefaultCxfRsBinding looks like:
Exchange
in : [MyPayload]
out : [MyPayload]
an everything is fine.
Sergey Beryozkin-3 wrote
> I'm also slightly concerned that if if we have roots explicitly checking
> for 204 (or indeed roots dealing with HTTP responses having no actual
> body) then this patch might affect them ?
Hmm, the Camel FAQ is saying that only using the in message should be fine:
Camel FAQ
<http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html>
But maybe in some circumstances it will affect some routes, I have to think
about it.
Sergey Beryozkin-3 wrote
> May be, in case of CXF RS binding, checking IN should be optional,
> example, if an exchange property is set allowing for it then do it,
> otherwise not. What do you think ?
Well, in my opinion it should in every case be consintent to the
DefaultCxfBinding. If it is made optional which I think is not a bad idea it
should be made optional for both DefaultCxfBinding and DefaultCxfRsBinding.
Regards
Dominik
--
View this message in context:
http://camel.465427.n5.nabble.com/DefaultCxfRsBinding-only-uses-Exchange-getOut-tp5744605p5744622.html
Sent from the Camel - Users mailing list archive at Nabble.com.
