Forgot that CXF HTTP can also be done as a filter now too, starting from
CXF 2.7.6 and CXF 2.7.7, though that enhancement that Dan did was
nothing to do with JAX-RS, so that distinction I mentioned does not
really exist I guess now.
The distinctions then are to do with various extensions, you can easily
find what Jersey offers on top of their JAX-RS impl on their site
Sergey
On 30/10/13 10:49, Sergey Beryozkin wrote:
On 29/10/13 22:23, KARR, DAVID wrote:
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Tuesday, October 29, 2013 9:31 AM
To: [email protected]
Subject: Re: In JAX-RS, what do you think distinguishes CXF from Jersey?
Hi David
On 24/10/13 16:11, KARR, DAVID wrote:
To both maintainers and users, what do you think distinguishes the
JAX-RS
implementation in CXF with Jersey?
I'd say that real evidence and experience is more informative than
"feelings".
IMHO comparing JAX-RS implementations alone is not really interesting
these days.
What drove us from the get go (meaning the point of time where we
started doing an RS frontend in addition to the established WS one) was
the idea of CXF supporting various styles of doing web services really
well, so that we could diversify CXF and have a wider community of
users. The element of trying to matching what Jersey could do was there
at the early days as we had some hard time getting the project supported
in the 1st place, this is no longer the case.
This comparison can be of more interest to the users who only would like
to stay within the pure JAX-RS without trying any of CXF extensions. To
that end I can say CXF JAX-RS is implemented as a CXF filter sitting
behind the servlets, while Jersey and RestEasy are, AFAIK, servlet
filters.
Ok, I suppose that's a distinction, but is there any real impact
either way from that difference?
I guess you need to experiment and see which implementation does better
for your requirements. May be other stacks can offer non servlet filter
options too, I don't really care
A year or so ago I'd probably say if you need to align with Java EE only
by working with a complete package, then Jersey or RestEasy can do
better, but I know now we have TomEE+ and also users using CXF RS with
the established EE containers - the latter though means that such users
can only get a support on this list and via a custom subscription with
one of the companies offering a CXF support.
Today, for me, it is all about making the RS project practically
successful, and so that it can work well with the rest of CXF, as
opposed to trying to make sure it does not lose to Jersey or RestEasy
which are of course are good implementations on its own.
Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
