Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.192.174 as permitted sender)
Date: Thu, 12 Dec 2013 17:49:12 +0800
From: Willem Jiang <willem.jiang@gmail.com>
To: users@camel.apache.org
Message-ID: <etPan.52a9869b.19495cff.322@localhost>
In-Reply-To: <52A8A273.2030504@gmail.com>
References: <1386775577193-5744605.post@n5.nabble.com>
 <52A8854A.6090107@gmail.com> <1386777190191-5744609.post@n5.nabble.com>
 <52A88F34.5030107@gmail.com> <1386781332507-5744622.post@n5.nabble.com>
 <52A8A273.2030504@gmail.com>
Subject: Re: DefaultCxfRsBinding only uses Exchange.getOut()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I will take care of it.

-- =20
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 =20
Weibo: =E5=A7=9C=E5=AE=81willem


On December 12, 2013 at 1:36:19 AM, Sergey Beryozkin (sberyozkin=40gmail.=
com) wrote:
> =20
> Hi
> On 11/12/13 17:02, Dominik Amon wrote:
> > Hi Sergey,
> >
> > i created a JIRA ( https://issues.apache.org/jira/browse/CAMEL-7061 =20
> > =20
> ).
> >
> Thanks
> >
> >
> >
> > Sergey Beryozkin-3 wrote
> >> What I'm not understanding yet is what kind of response you =20
> actually get
> >> if IN message is checked =3F
> >
> > The problem in my case is that the last action of the TryProcessor =20
> is moving
> > the out message to the in message, thus setting the out message =20
> to null.
> > Now when the CxfRsInvokers returnResponse method is called, =20
> which populates
> > the response using the DefaultCxfRsBinding (calling
> > endpoint.getBinding().populateCxfRsResponse=46romExchange(camelExchan=
ge, =20
> > cxfExchange))the exchange looks like:
> >
> > Exchange
> > in : =5BMyPayload=5D
> > out : null
> >
> > and the DefaultCxfRsBinding currently only uses the out message =20
> and if the
> > out message is null cxfrs returns the http response code 204. =20
> >
> > When removing the block the exchange that arrives at =20
> the
> > DefaultCxfRsBinding looks like:
> >
> > Exchange
> > in : =5BMyPayload=5D
> > out : =5BMyPayload=5D
> >
> > an everything is fine.
> >
> Clear, thanks
> >
> > Sergey Beryozkin-3 wrote
> >> I'm also slightly concerned that if if we have roots explicitly =20
> checking
> >> for 204 (or indeed roots dealing with HTTP responses having =20
> no actual
> >> body) then this patch might affect them =3F
> >
> > Hmm, the Camel =46AQ is saying that only using the in message should =
=20
> be fine:
> > Camel =46AQ
> > =20
> >
> > But maybe in some circumstances it will affect some routes, =20
> I have to think
> > about it.
> >
> Please do.
> >
> > Sergey Beryozkin-3 wrote
> >> May be, in case of CX=46 RS binding, checking IN should be optional,=
 =20
> >> example, if an exchange property is set allowing for it then =20
> do it,
> >> otherwise not. What do you think =3F
> >
> > Well, in my opinion it should in every case be consintent to the =20
> > DefaultCxfBinding. If it is made optional which I think is not =20
> a bad idea it
> > should be made optional for both DefaultCxfBinding and DefaultCxfRsBi=
nding. =20
> >
> Typical SOAP response will not be empty, may be only in advanced =20
> WS-RM
> scenarios, so I guess it is very safe for the DefaultCxfBinding. =20
> =20
> That said, your patch is likely very safe, now that I think about =20
> it, if
> we have routes with 204 or 302, etc, they won't have the response =20
> body
> anyway, please think a bit more about such cases, but I guess your =20
> patch
> would be good to go
> =20
> Thanks, Sergey
> > Regards
> > Dominik
> >
> >
> >
> > --
> > View this message in context: http://camel.465427.n5.nabble.com/Defau=
ltCxfRsBinding-only-uses-Exchange-getOut-tp5744605p5744622.html =20
> > Sent from the Camel - Users mailing list archive at Nabble.com. =20
> >
> =20
> =20