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

From: <>
Date: Fri, 23 May 2014 15:34:08 +0000 (UTC)

Sergey Beryozkin wrote:

SB> Look forward to JAX-RS supporting MVC and SSE. As far as the future
SB> JAX-RS MVC is concerned, I hope it will not only target EE users
SB> though :-).

I think we can keep that requirement in mind, but the sweet spot, and
center of efforts for the solution is going to be when running in an EE
container. We expect a key portion of the value add with be usage of
CDI and select JSF concepts: Facelets, @FlowScoped, @ViewScoped, and

SB> i.e, it would work even if no JSF is available, but of
SB> course the input from JSF experts will be of great interest.

Yes, it would work, just as Jersey MVC works right now, but that
solution leaves a lot of value unused when running in EE.

Here is a brief summary the discussion that happened on
users_at_javaserverfaces-spec-public thus far, staring with Arjan's
on Fri, 28 Feb 2014 23:14:52 +0100 [1] and completing with Leonardo's
last message on the thread at Tue, 8 Apr 2014 18:22:44 +0200 [2].

Arjan pointed out the work Manfred did to build the action oriented
framework on top of the JSF lifecycle mechanism.

Adrian Gonzalez wrote:

AG> Both JAX-RS and JSF miss some features for a MVC framework. JSF
AG> misses (at least) the following stuff to support reasonably well
AG> MVC scenario :

AG> 1. it doesn't support for now HTTP REST usage : HTTP PUT, POST
AG> (without postback), DELETE, etc... This is a blocker.

AG> 2. templating : plugging in a 3rd party templating engine easily
AG> should be supported in MVC.

AG> This is not the case for a component and an action based
AG> framework. As I recall, Spring MVC has been built after
AG> JAX-RS. Spring MVC authors didn't used JAX-RS because it was too
AG> limiting for them . Perhaps someone should ask them why JAX-RS was
AG> too limiting in order to lift those limitations ?

AG> As for PlayFramework, I didn't used it, but here are some goodies :

AG> * code reloading - a must have !

AG> * view are compiled so you can use them in the controllers (to
AG> populate the view and to navigate to them).

AG> * view templates (and form helpers) are more
AG> than the same in JSP / facelets.

Andy Bosch wrote:

AB> Of course I am in favour of enhancing JSF according to user
AB> feedback. But I am not sure whether it is a good idea to integrate
AB> too much into it.

Ed Burns wrote:

EB> I'd like to see us extract Facelets from JSF, make it a first class
EB> citizen of a JAX-RS MVC, *and* provide an Action Oriented
EB> lifecycle as an alternative to the standard JSF lifecycle.

Andy Bosch replied:

AB> In my personal opinion it sounds good. But I often hear complaints
AB> of people about the JSF lifecycle (mostly those people do not like
AB> JSF at all ;-) ). Some people just don't like a complex
AB> lifecycle. They prefer having a simple controller that is called
AB> during an action invocation.

AB> So to sum up I would say we have to carefully think about how
AB> complex or easy such an lifecycle would become.

Kito Mann asked:

KM> Ed, what's your motivation for doing the JAX-RS route _and_ the JSF
KM> route? Support action-based scenarios within JSF apps, but provide
KM> JAX-RS for those who don't use JSF?

Ed Burns replied:

EB> Right, it's about making Facelets available outside of JSF because
EB> templating is useful on its own, even without the JSF lifecycle.

Leonardo Uribe responded by asserting that the combination of Spring
*and* JSF can be powerful, citing a blog entry and examples.

LU> In other words, what the user want is in this case is:

LU> - Take advantage of JSF 2 template system (facelets) and component
LU> model.

LU> - Don't use the JSF lifecycle and use something else that fits.

Leonardo further asserts it is nonsense to take Facelets out of JSF:

LU> If you take facelets out of JSF, what you are really doing is get
LU> rid of JSF lifecycle, but besides that, you are not doing anything
LU> else.

Frank agreed with Leonardo's assertion.

Though I agree with all of Leonardo's other points in his response, I
disagree with this one. You are getting all the page templating from
the <ui:> tag library which doesn't exist in any other server side java
solution aside from Struts Tiles.

Leonardo goes on to sketch a solution to allow JSF to plug more cleanly
into Spring MVC, providing specific details about how the JSF lifecycle
can be improved in the process.

Taking another perspective on the matter, Leonardo outlines the
data-only JSF lifecycle idea we've been kicking around for years and
discussed at Javaland. The basic idea is to have a way for a JSF ajax
request to have access to all JSF features except those relating
directly to a view. This would include FacesContext, Flash, Flow, etc
but would *NOT* include anything to do with a specific view. This is
captured in JAVASERVERFACES_SPEC_PUBLIC-1261 and I want to pursue this
in JSF 2.3.

The discussion continued after Javaland. Frank sketched out how you
could forward from JAX-RS to the FacesServlet today, even without
MVC. Leonardo replied,

LU> The only flaw I can see is using ExternalContext there is no way to
LU> know when the request is a GET, a POST and so on, which is
LU> at the time to define the endpoint.

LU> Now, it could be useful to have a "action source framework"
LU> component. That means, an special component that work in a way that
LU> everything inside it works just like any action source framework,
LU> but everything outside the box still work under JSF rules.

LU> So, other people has already thought the same as we are trying to
LU> and have been doing (JSF 2.2 viewAction and JSF 2.0 viewParam),
LU> there are some cases where an action oriented approach with a
LU> component oriented framework can coexist. In that sense, the
LU> to define REST services inside CDI managed beans through Faces
LU> Servlet seems to be important. For what? It is not hard to find
LU> cases. For example, to expose information to some other app or
LU> component or service that consume it as a REST service. If you have
LU> a JSF webapp nothing can be simpler as define the method right on
LU> the managed bean.

Leonardo followed up on this with some very detailed suggestions.
Leonardo, please join the discussion over on He ends by summarizing:

LU> For some users who currently uses JSF at a daily basis, this
LU> is not something important, because there is a workaround and this
LU> usually suppose a small part of the whole application, so you don't
LU> really spent a lot of time solving it. It is not really hard to
LU> write a couple of servlets that can do the job in these cases.

LU> But for some other users that are not into JSF, this is
LU> important. The reason is JSF Template engine (Facelets) solves a
LU> of problems for them. These guys usually are making applications
LU> with another architectural paradigm, different to the one proposed
LU> initially by JSF.

Let's get moving!