You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Dominik Amon <do...@iso-gruppe.com> on 2013/12/11 16:26:17 UTC

DefaultCxfRsBinding only uses Exchange.getOut()

Hi,

I currently stumbled upon an issue when using camel cxfrs component. Where I
only get response code 204 - No Content when the route has a <doTry> block.

I am using Camel 2.12.2 and Blueprint.

The route is like:

<route id="myRoute">
    <from uri="cxfrs://bean://serviceBean"/>
    <doTry>
        <to uri="direct-vm:test"/>
        <to uri="log:test?showAll=true"/>
        <doFinally>
            <to uri="log:finally?showAll=true"/>
        </doFinally>
    </doTry>
</route>

I had a look in the DefaultCxfRsBinding.java where the method
populateCxfRsResponseFromExchange(...) only uses exchange.getOut().getBody()
as return value.

Whereas in the DefaultCxfBinding.java the response is either retrieved from
the IN or the OUT.

I have created a patch for DefaultCxfRsBinding that fetches the body in the
same way as DefaultCxfBinding does. Now it seems to work.

So my question is this intended that the DefaultCxfRsBinding only calls
exchange.getOut().getBody() or should it be also like in the
DefaultCxfBinding?

Regards
Dominik Amon

DefaultCxfRsBinding.patch
<http://camel.465427.n5.nabble.com/file/n5744605/DefaultCxfRsBinding.patch>  



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

Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Dominik Amon <do...@iso-gruppe.com>.
Hello Willem,


Willem.Jiang wrote
> I will take care of it.
> 
> --  
> Willem Jiang
> 
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/)
> (English)
> http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang  
> Weibo: 姜宁willem

Thank you for that.

Regards
Dominik



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

Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Willem Jiang <wi...@gmail.com>.
I will take care of it.

--  
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem



On December 12, 2013 at 1:36:19 AM, Sergey Beryozkin (sberyozkin@gmail.com) wrote:
>  
> Hi
> On 11/12/13 17:02, Dominik Amon wrote:
> > Hi Sergey,
> >
> > i created a JIRA ( https://issues.apache.org/jira/browse/CAMEL-7061  
> >  
> ).
> >
> Thanks
> >
> >
> >
> > 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 block the exchange that arrives at  
> the
> > DefaultCxfRsBinding looks like:
> >
> > Exchange
> > in : [MyPayload]
> > out : [MyPayload]
> >
> > an everything is fine.
> >
> Clear, thanks
> >
> > 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
> >  
> >
> > But maybe in some circumstances it will affect some routes,  
> I have to think
> > about it.
> >
> Please do.
> >
> > 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.  
> >
> Typical SOAP response will not be empty, may be only in advanced  
> WS-RM
> scenarios, so I guess it is very safe for the DefaultCxfBinding.  
>  
> That said, your patch is likely very safe, now that I think about  
> it, if
> we have routes with 204 or 302, etc, they won't have the response  
> body
> anyway, please think a bit more about such cases, but I guess your  
> patch
> would be good to go
>  
> Thanks, Sergey
> > 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.  
> >
>  
>  


Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 11/12/13 17:02, Dominik Amon wrote:
> Hi Sergey,
>
> i created a JIRA ( https://issues.apache.org/jira/browse/CAMEL-7061
> <https://issues.apache.org/jira/browse/CAMEL-7061>  ).
>
Thanks
>
>
>
> 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.
>
Clear, thanks
>
> 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.
>
Please do.
>
> 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.
>
Typical SOAP response will not be empty, may be only in advanced WS-RM 
scenarios, so I guess it is very safe for the DefaultCxfBinding.

That said, your patch is likely very safe, now that I think about it, if 
we have routes with 204 or 302, etc, they won't have the response body 
anyway, please think a bit more about such cases, but I guess your patch 
would be good to go

Thanks, Sergey
> 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.
>


Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Dominik Amon <do...@iso-gruppe.com>.
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.

Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>



Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Dominik Amon <do...@iso-gruppe.com>.
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.

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.

Re: DefaultCxfRsBinding only uses Exchange.getOut()

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,

On 11/12/13 15:26, Dominik Amon wrote:
> Hi,
>
> I currently stumbled upon an issue when using camel cxfrs component. Where I
> only get response code 204 - No Content when the route has a <doTry> block.
>
> I am using Camel 2.12.2 and Blueprint.
>
> The route is like:
>
> <route id="myRoute">
>      <from uri="cxfrs://bean://serviceBean"/>
>      <doTry>
>          <to uri="direct-vm:test"/>
>          <to uri="log:test?showAll=true"/>
>          <doFinally>
>              <to uri="log:finally?showAll=true"/>
>          </doFinally>
>      </doTry>
> </route>
>
> I had a look in the DefaultCxfRsBinding.java where the method
> populateCxfRsResponseFromExchange(...) only uses exchange.getOut().getBody()
> as return value.
>
> Whereas in the DefaultCxfBinding.java the response is either retrieved from
> the IN or the OUT.
>
> I have created a patch for DefaultCxfRsBinding that fetches the body in the
> same way as DefaultCxfBinding does. Now it seems to work.
>
> So my question is this intended that the DefaultCxfRsBinding only calls
> exchange.getOut().getBody() or should it be also like in the
> DefaultCxfBinding?
Can you explain please how retrieving an IN body helps in the case of 
204 ? What happens without applying a patch ?

Thanks, Sergey

>
> Regards
> Dominik Amon
>
> DefaultCxfRsBinding.patch
> <http://camel.465427.n5.nabble.com/file/n5744605/DefaultCxfRsBinding.patch>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DefaultCxfRsBinding-only-uses-Exchange-getOut-tp5744605.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>