[jax-rs-spec users] [jsr339-experts] Re: MVC

From: Markus KARG <>
Date: Mon, 30 Jun 2014 20:03:47 +0200


>> I gave the topic another thought from the aspect of Java EE as a
>> platform (ignoring REST), and like to add that I see the technical
>> merits of combining the two technologies JAX-RS and JSF into one. In
>> coarse, redefining JSF to become an implementation of the JAX-RS
>> 'Feature' interface providing Filters, Entity Providers and Exceptions
>> Mappers, and dropping all its internal plumbing in favour of JAX-RS,
>> is actually appealing. This won't change anything w.r.t. existing
>> JAX-RS, but it would spare JSF implementations some duplicate code,
>> obviously, as the JAX-RS-Servlet and the JSF-Servlet mostly do the
>> similar things internally (path matching, parsing, rendering,
>> exception handling, CDI, ...). The "simple" difference between JAX-RS
>> and JSF is that the first is for machine users, the latter for human
> This is simply not correct. JAX-RS is primarily about streamlining the
development of server-side REST or simple HTTP applications.

You are right with that, but you misunderstood what I wanted to say. Looking
from a bird's view on both, JSF and JAX-RS, you will notice that both's
action look similar: A request comes in, pets matched on some kind of
resource, content gets parsed, forwarded to a back end, back end returns
data, data gets rendered, response gets send. That cycle, and lots more, is
effectively something which could be shared. Certainly it is not the idea to
make JSF become part of JAX-RS, that would foil the REST idea of that API. I
could imagine that the JSF EG can rebuild JSF around JAX-RS's core
implementation, like being an entity provider. I expect that we team up with
them to defined the small missing bricks in JAX-RS so they can do that and
spare a lot of their existing code. But I do not expect the JAX-RS EG to
provide JSF, certainly. That's why I wrote, I would simply ask the JSF guys
to team up with us, so we can jointly provide a second PDF which clarifies
JAX-RS-*based* MVC. It solely will define how JSF (and others) can use
JAX-RS to replace their own internal plumbing. It will *not* enforce any
JAX-RS implementation of provide JSF (or any other human-readable rendering