> -----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?

> 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

Reply via email to