Hi Dominik

Sure, thanks for the clarifications.
Please open a JIRA and attach your patch there, I can do it on your behalf but I guess it would be better for the actual contributor to do it.nding

In meantime, let me ask few more questions:
On 11/12/13 15:53, Dominik Amon wrote:
Hello Sergey

I debugged a bit further into camel and found out that the TryProcessor
calls

ExchangeHelper.prepareOutToIn(exchange)

so at the time of populating the CxfRSResponse from the the exchange the Out
is always null in my case. When I remove the the <doTry> and <doFinally> I
get a response, otherwise I only get an empty response with response code
204.

What I'm not understanding yet is what kind of response you actually get if IN message is checked ?

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 ?

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 ?

Sergey

As already said, the DefaultCxfBinding class already uses either the in or
the out body for populating the response.

So if switching to SOAP everything works just fine.

See class org.apache.camel.component.cxf.DefaultCxfBinding, method
populateCxfResponseFromExchange(...):

     public void populateCxfResponseFromExchange(Exchange camelExchange,
             org.apache.cxf.message.Exchange cxfExchange) {

         8< --- SNIP --->8

         org.apache.camel.Message response;
         if (camelExchange.getPattern().isOutCapable()) {
             if (camelExchange.hasOut()) {
                 response = camelExchange.getOut();
                 LOG.trace("Get the response from the out message");
             } else { // Take the in message as a fall back
                 response = camelExchange.getIn();
                 LOG.trace("Get the response from the in message as a
fallback");
             }
         } else {
             response = camelExchange.getIn();
             LOG.trace("Get the response from the in message");
         }

         8< --- SNIP --->8
     }

And for cxfrs, see class
org.apache.camel.component.cxf.jaxrs.DefaultCxfRsBinding, method
populateCxfRsResponseFromExchange(...):

      public Object populateCxfRsResponseFromExchange(Exchange camelExchange,

org.apache.cxf.message.Exchange cxfExchange) throws Exception {
         if (camelExchange.isFailed()) {
             throw camelExchange.getException();
         }

         return camelExchange.getOut().getBody();
     }

So it seems like there are there are two different things.

1. DefaultCxfBinding (SOAP) behaves different than DefaultCxfRsBinding
(JAXRS) when populating the response from an exchange

2. In my case the <doTry> moves the out to the in of the exchange and thus
cxfrs does not populate the response.

Regards
Dominik




--
View this message in context: 
http://camel.465427.n5.nabble.com/DefaultCxfRsBinding-only-uses-Exchange-getOut-tp5744605p5744609.html
Sent from the Camel - Users mailing list archive at Nabble.com.



Reply via email to