Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of elakito@googlemail.com
 designates 209.85.161.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAF8t5XtXZp7DkKxYxrbvdtqzQ8Wh3+MSxxvEikrV0hPB_qYhQQ@mail.gmail.com>
References: <7675628.7334.1315562109425.JavaMail.tomcat@hel.zones.apache.org>
	<1096981606.8029.1315576928786.JavaMail.tomcat@hel.zones.apache.org>
	<CAF8t5Xvur_pAZxRZ=Tv-Lrgnpofaj+5wRNxQBFbwfVT52p6kUg@mail.gmail.com>
	<4E7093D8.6060103@gmail.com>
	<CAF8t5XtXZp7DkKxYxrbvdtqzQ8Wh3+MSxxvEikrV0hPB_qYhQQ@mail.gmail.com>
Date: Wed, 14 Sep 2011 18:51:45 +0200
Message-ID: 
 <CAF8t5XvXf98Q0K4=zvZaXA=aCRyrp=jxyG9chuzFH77CYGeqvA@mail.gmail.com>
Subject: Re: [jira] [Resolved] (CAMEL-4429) CXFProducer should tell CXF to
 ignore the part response handling when it uses MESSSAGE dataformat
From: Aki Yoshida <elakito@googlemail.com>
To: Willem Jiang <willem.jiang@gmail.com>
Cc: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Willem,
I found where this 500 originally comes from (there is an NPE raised
in RawMessageContentRedirectInterceptor when no PR is returned). I
will verify this condition a little more and will update the ticket
with the patch.
thanks.
regards, aki

2011/9/14 Aki Yoshida <elakito@googlemail.com>:
> Hi Willem,
> thanks.
>
> I just tried the camel-trunk's test case against CXF 2.5.0-SNAPSHOT
> without this property set. The twoway greeter calls (greetMe and
> sayHi) are not blocked and worked fine. But the greeter.greetMeOneWay
> call seems to throw an exception after the call is completed. And this
> exception is returned back from the RouterPort as HTTP 500 and the
> test is failing.
>
> So, the original blocking behavior is not there any more but there is
> still a problem.
>
> I will look into this.
>
> Regards, aki
>
>
> 2011/9/14 Willem Jiang <willem.jiang@gmail.com>:
>> Hi Aki
>>
>> The test case is part of the test of CxfGreeterMessageRouterTest in the
>> camel-cxf module.
>> I just built the latest cxf-2.4.x branch and run the test.
>> The test failed if I doesn't set the option which is introduced in
>> CAMEL-4429 on the CxfProducer :(.
>>
>> As the CxfProducer doesn't know the binding operation as it doesn't chec=
k
>> the underlay input steam, I still need to use the option to let HttpCond=
uit
>> do not consume the underlay message.
>>
>> Willem
>>
>> On 9/14/11 6:33 PM, Aki Yoshida wrote:
>>>
>>> Hi Willem,
>>>
>>> I updated the patch for CXF-3788 to avoid the problem you discovered
>>> for the original patch. I have tested the updated patch against a jaxw
>>> disptach test case in CXF. I would like to verify that this correction
>>> works for the test case you had without using this request property
>>> setting. Is your test case in the camel-cxf test folder? If not, could
>>> you tell me which one?
>>>
>>> Thanks.
>>> regards, aki
>>>
>>> 2011/9/9 Willem Jiang (JIRA)<jira@apache.org>:
>>>>
>>>> =A0 =A0 [
>>>> https://issues.apache.org/jira/browse/CAMEL-4429?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel
>>>> ]
>>>>
>>>> Willem Jiang resolved CAMEL-4429.
>>>> ---------------------------------
>>>>
>>>> =A0 =A0 =A0 Resolution: Fixed
>>>> =A0 =A0Fix Version/s: 2.8.2
>>>>
>>>> Applied patch into trunk and Camel 2.8.x branch.
>>>>
>>>>> CXFProducer should tell CXF to ignore the part response handling =A0w=
hen
>>>>> it uses MESSSAGE dataformat
>>>>>
>>>>> ---------------------------------------------------------------------=
-----------------------------
>>>>>
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: CAMEL-4429
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: https://issues.apache.org/jira/b=
rowse/CAMEL-4429
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 Project: Camel
>>>>> =A0 =A0 =A0 =A0 =A0Issue Type: Improvement
>>>>> =A0 =A0 =A0 =A0 =A0Components: camel-cxf
>>>>> =A0 =A0 =A0 =A0 =A0 =A0Reporter: Willem Jiang
>>>>> =A0 =A0 =A0 =A0 =A0 =A0Assignee: Willem Jiang
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 Fix For: 2.8.2, 2.9.0
>>>>>
>>>>>
>>>>> IN CXF-3788, CXF HTTPConduit will handle the partial response when th=
e
>>>>> HTTP response code is 202 nor matter the operation is oneway or not. =
It will
>>>>> cause the camel-cxf producer wait for the response for server for eve=
r.
>>>>> CXF-3796 introduces a new message header to help us to workaround thi=
s
>>>>> issue, we need to set this header in CxfProducer when the data format=
 is
>>>>> MESSAGE.
>>>>>
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> For more information on JIRA, see: http://www.atlassian.com/software/j=
ira
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>