[javaee-spec users] Re: [jsr342-experts] report on EG meeting at JavaOne

From: arjan tijms <>
Date: Sat, 5 Oct 2013 00:39:06 +0200

Hi Marek,

Thanks a lot for the pointers. They surely help clarifying the proposal.

I do have a couple of concerns still.

The first is that as far as I can see (correct me if I'm wrong) all the
examples and documentation exclusively talk about JSP and FreeMarker. JSF
is never mentioned. Whether it's intended or not, I think this does
somewhat give the impression that a competing web framework is being

I mean, this was my first reaction when I first read the (now closed) spec
issue, the slide more or less said it and various people whom I showed the
examples to pretty much had the same reaction.

If the intend is to make Java EE a more integrated and coherent platform I
feel the proposal should at least explain how it relates to JSF and if
possible in what ways it could integrate with it. Looking back at CDI
(competitor for JSF's native managed beans) and Bean Validation (competitor
in some way for JSF's own validators), we saw that from the beginning both
had something to say about JSF. The end result integrates really well with
JSF (and other specs), yet has enormous value on its own as well.

The second concern is about the point at which a JAX-RS MVC controller is
called. Without any specific integration I guess it must be called before
the FacesServlet is invoked. This may reduce its value for JSF, since at
that point the FacesContext isn't yet available. If the FacesContext is not
available you can not easily do things like setting a faces message, e.g.
for when conversion and/or validation of request parameters failed. You
also can't conveniently use the standard APIs to check if a given request
is a postback or not, etc.

For JSF it would probably be more appropriate if the JAX-RS controller
would be called after the FacesServlet. I'm not really sure if this is 100%
feasible, but maybe it could work via a special integration JAX-RS
controller that's mapped to the URL patterns of all user supplied
controllers for JSF, and which calls the FacesServlet with the right
metadata so this one on its turn can call the actual user supplied
controller. Again, not sure if this is feasible, but just thinking out loud

Yet another concern is the exact method via which another resource (JSF
view, JSP page, etc) is invoked. Does this happen via a Servlet (request
dispatcher) forward? A forward typically has some side-effects when the
application also uses Servlet Filters, which in a JSF application is
typical for e.g. security, response gzipping etc. This is especially true
if not all requests to JSF views are forwards. For the Faces Views feature
in OmniFaces, which was originally based on forwards as well, we spend
quite some time compensating for those side-effects.

Kind regards,
Arjan Tijms

On Friday, October 4, 2013, Marek Potociar wrote:

> I think there is some confusion about what JAX-RS MVC is about, so before
> we dive deep in that discussion, let me clarify what JAX-RS MVC means:
> We DO NOT want to invent new MVC framework in JAX-RS. We merely want to
> expose API and SPI for integrating JAX-RS resources with existing MVC
> frameworks (JSF, JSP, FreeMarker, Moustache, ...). Essentially, we want to
> be able to send any response generated by a JAX-RS resource to a templating
> engine (or MVC framework, if you like) that can produce a views based on
> the response model JAX-RS resource provide and based on the template the
> templating framework will used to generate the ultimate HTTP response
> content. So, in a way it's similar to ASP.NET razor templates (
> See here for more on what we already do in Jersey to support MVC
> templates:
> Or check one of our examples that use Jersey MVC:
> Thanks,
> Marek
> On Oct 3, 2013, at 5:32 AM, arjan tijms <> wrote:
> On slide 19, "JAX-RS MVC"
> I agree with the central question "Do we really need another standard web
> framework?", and would like to specifically add the question "*Why* would
> we want a second web framework?"
> Is it because JSF is not popular enough, or are there specific use cases
> JSF can't address?
> As many of you may know, the web framework space is highly fragmented and
> fans of the many different frameworks can be very vocal. A few years ago
> Wicket saw a surge in popularity, but barely half a year later it was all
> about GWT, and then it was about Spring MVC, then Play! and then about
> "HTML5" and a slew of JavaScript based frameworks.
> Meanwhile there are proponents of both the component-oriented and
> action-oriented model. JSF being a prime representative of the
> component-oriented model got a lot of bad press in the beginning, which may
> have led to the idea that component-oriented frameworks were not ideal. But
> ever since JSF 2.0 there has been a massive reduction of complaints against
> JSF. Currently I often see JSF (and PrimeFaces) being recommended by users
> as reply on questions about which framework to use.
> Just a random example:
> User 1: "What are some good frameworks to get started with?"
> User 2: "I would go with JSF and PrimeFaces. This is a modern web
> development framework. There is still a lot of Spring MVC out there but a
> lot of it has become redundant to the standard JEE."
> (see
> )
> So if a "JAX-RS MVC" is just to make Java EE more popular for web
> applications with the general public then that might not be entirely
> necessary any more.
> As for the technical merits of an action-oriented web framework we've seen
> that JSF has adopted some aspects of it lately. JSF 2.0 introduced view
> parameters and the preRenderView event, which allow users to implement some
> action-oriented like behaviour. JSF 2.2 further went into this direction
> with the introduction of view actions and the beginning of a stateless mode.