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 (sberyoz...@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.  
> >
>  
>  

Reply via email to