cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: More cache in jaxrs impl
Date Fri, 10 May 2013 15:46:34 GMT
Basically writing a custom provider preinitializing contexts if genrerally
far better and trivial
Le 10 mai 2013 17:18, "Sergey Beryozkin" <> a écrit :

> Hi Romain
> On 10/05/13 11:03, Romain Manni-Bucau wrote:
>> Hi,
>> It doesnt urge (and im cleaning up tomee after the owb update which broke
>> a
>> bunch of stuff for weeks so no real time ATM ;) but saw it several times
>> integrating cxf in tomee and each time i tested/debugged doing a POST data
>> provisioning i was womdering why it was so complicated since it was the
>> same than previous query. Finally found time to start discussing it here
>> :)
>> What would be great: ok for a param but on server factory bean too to let
>> tomee activate it if possible, backported in 2.6.x otherwise tomee 1.x
>> will
>> not be able to be certified :(
>> Then the key of the cache should only be composed of the fixed uri, http
>> method, consume  and produce media type no? Kind of light
>> OperationResourceInfo
> We'll have to think carefully about it; at the moment I'm not sure if/how
> it will work, perhaps a limited optimization is possible, I'm thinking more
> about eliminating the possibly redundant checkups after a first candidate
> has been found, etc or when the resource has such operations that it can
> become safe to cache, I'm not sure really at the moment.
> I was thinking more about the servlet level optimization
> Cheers, Sergey
>  Le 10 mai 2013 11:51, "Sergey Beryozkin"<sberyozkin@gmail.**com<>>
>>  a écrit :
>>  Hi Romain
>>> On 10/05/13 10:27, Romain Manni-Bucau wrote:
>>>  Hi guys
>>>> Excepted if i didnt get the code right it seems the endpoint resolution
>>>> is
>>>> done each time in rs impl.
>>>> Couldnt it be cached a bit more? (i think to fixed uri which is common
>>>> for
>>>> not GET cases). In such a case cxf could skip a bunch of logic no?
>>>> The idea is to get perf closer to servlets since jaxrs is close to them
>>>> (i
>>>> never said it was the same ;)
>>>> Wdyt?
>>>>   I think it is a not a bad idea at all. We can try to experiment with
>>>> it
>>> by introducing an optional servlet parameter so that we can always resort
>>> to the existing tried and tested approach if needed. The only thing it
>>> can
>>> be tricky to do completely right.
>>> For SOAP endpoints it can be more predicatable, for RS endpoints a bit
>>> less, as we effectively have a stem match. Please start experimenting if
>>> you need it fast, I'm all into JAX-RS 2.0 work now with some other
>>> planned
>>> work to do, but can help with/look into it later on too.
>>> Thanks, Sergey

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