Hi,
On 10/05/13 12:47, Bill Burke wrote:
Hope you don't mind giving my 2-cents based on Resteasy.
Unless you're doing in-memory mock JAX-RS invocations, I've found that
any overhead of JAX-RS is pretty much dwarfed by any
marshalling/unmarshalling of entities i.e. JSON/XML. I've also found
that there's a lot of static processing you can do that still fits under
spec requirements.
Good points,
I've been interpreting the proposal such that some optimization may
optionally be applied to the servlet-level code where CXF endpoints are
selected, before the JAX-RS runtime even starts matching the request URI.
But I now realize Romain would like to go a bit further :-). Indeed, the
scope for the optimization is limited at the matching level, but perhaps
something may be possible to optimize, not quite sure yet what, the only
thing that seems certain is that it makes sense when we have resources
with many operations...
Cheers, Sergey
On 5/10/2013 5:50 AM, Sergey Beryozkin wrote:
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
