cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Refactoring of JAXRSInvoker to support CXF continuation better
Date Mon, 22 Nov 2010 17:46:10 GMT
Hi Willem

I've spent some today on applying your patch which is what I did but with
some major changes, hope that you can get your tests passing with the new
code, see

http://svn.apache.org/viewvc?rev=1037786&view=rev.

One thing I had to ensure that the root instance remains visible to the
JAXRSOutInterceptor. Depending on the way the prototype beans have been set
up, the 'destroy' method can be called on prototypes either immediately
after the invocation or after the response object has been completely
processed (serialized). Thus I could not use JAXRSUtils.ROOT_RESOURCE to
mark the subresources instances.

There were some issues with the returning invocation erroneously
contributing to the invocation stach which is traced and reported by JAX-RS
UriInfo.

So it all should work well now.

One snag which caused me some 'grief' was that I took me some time that the
refactoring which was done on the CXF Continuation code was *breaking* to
some extent.

Particularly, continuation.suspend() does not return immediately. Thus when
used directly in the application code, for ex, as shown in the
JAXRSContinuationsTest, one now has also add an explicit return.

I'll start another dev thread

thanks for your help, Sergey





On Fri, Nov 19, 2010 at 10:11 AM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:

> Hi Willem
>
> I see now...
> I will add a failing test to JAXRSContinuationsTest suite and apply your
> patch.
> many  thanks :-)
>
> Sergey
>
> On Fri, Nov 19, 2010 at 12:24 AM, Willem Jiang <willem.jiang@gmail.com>wrote:
>
>> On 11/18/10 8:49 PM, Sergey Beryozkin wrote:
>>
>>> Hi Willem
>>>
>>> thanks for working on it. The patch looks fine.
>>>
>>> Can you just explain please why the changes are needed given that
>>> JAXRSContinuationsTest is passing at the moment.
>>>
>> I just went through the JAXRSContinuationsTest, it doesn't test the
>> getSubResource part.
>>
>> I found the issue by running the camel-cxf test of
>> CxfRsRouterTest.testGetSubResource()[1]
>>
>>
>>  I suspect it is because the (Camel) code which relies on the enhanced CXF
>>> continuations code stresses the JAXRSInvoker differently, i.e, the
>>> suspended
>>> invocation is not coming back through the JAXRSInInterceptor ?
>>>
>> No, the CXF continuations API is not change, I just changed the underlay
>> implementation. When continuation suspend is called, we need to recover the
>> stats of ResourceProvider and ServiceObject in the exchange to make the
>> JAXRSInvoker.invoke() method recallable.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/jaxrs/CxfRsRouterTest.java
>>
>>
>>
>>> cheers, Sergey
>>>
>>>
>>> On Thu, Nov 18, 2010 at 10:18 AM, Willem Jiang<willem.jiang@gmail.com
>>> >wrote:
>>>
>>>  Hi,
>>>>
>>>> I did some clean up work[1] on the CxfRsInvoker in Camel to let it work
>>>> better with CXF 2.3.0 continuation API.
>>>>
>>>> Current JAXRSInvoker is not friendly to extends, and the method
>>>> public Object invoke(Exchange exchange, Object request)
>>>> is stateful and can't be called by the continuation resume process.
>>>>
>>>> Please check this issue[2] for the patch.
>>>>
>>>>
>>>> [1]http://svn.apache.org/viewvc?rev=1036343&view=rev
>>>> [2]https://issues.apache.org/jira/browse/CXF-3133
>>>> --
>>>> Willem
>>>> ----------------------------------
>>>> FuseSource
>>>> Web: http://www.fusesource.com
>>>> Blog:    http://willemjiang.blogspot.com (English)
>>>>         http://jnn.javaeye.com (Chinese)
>>>> Twitter: willemjiang
>>>>
>>>>
>>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog:    http://willemjiang.blogspot.com (English)
>>         http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message