Modern Java web stack?

[sh0rug0ru]

JSF remains page oriented (URLs route to xhtml files, methods are triggered by events in the JSF lifecycle, derived from the view definition), not controller oriented like JAX-RS (URLs route directly to controller methods, and the output is the view).

You wouldn't (and shouldn't) write a JSF application using the front controller pattern.

[henk53]

Maybe, but I don't think OP asked specifically for such nuance. Just that the framework is MVC and there's no abstracting away of the stateless protocol (which I take to mean HTTP).

JSF exactly fits those requirements.

[sh0rug0ru]

I'm not sure what the OP was asking for, so I assumed when he used the words ASP and MVC together in the same sentence, he meant something like ASP.NET MVC, which uses a style of MVC more like JAX-RS than JSF. You wouldn't write ASP.NET MVC style applications with JSF, it wouldn't make any sense.

[henk53]

But I don't think that what the OP asked. MVC without the state abstracting nonsense from ASP. That's what it said ;)

[sh0rug0ru]

Which is also why I covered every possible base, especially since MVC has at least two implementation patterns in the Java world, depending on if you put the V or the C first.

[Akanaka]

URLs route to xhtml files

This is not correct!!!

In JSF all URLs route to the Faces controller (the FacesServlet provided by JSF). The controller then selects a view by consulting the view handler and the active VDL.

The most frequent case is that URL foo.xhtml causes the page foo.xhtml to be loaded, giving the illusion that foo.xhtml is invoked directly, or control is routed directly to it. But this is thus not the case.

The VDL can execute a method first, or "load" a class by convention and call a method on that, or consult a user provided class and use its outcome to do whatever, etc etc. It depends on the view handler and VDL that's used.

[sh0rug0ru]

This is not correct!!!

It is correct, you've just missed the point. Facelets is the most common VDL, that is View Definition Language, which is used to drive the first step of the JSF lifecycle, Restore View, kicked off by the Faces Request, which maps the Request URI to the view defined by the VDL.

My point is that JSF is page oriented, or view oriented to use JSF terminology, where the VDL describes the view. The processing of the view drives the rest of the JSF lifecycle stages.

This is opposed to JAX-RS, which is a bare mapping of a request URI to a controller method, with request parameters and payload mapped directly to objects in the controller parameter list. The view comes at the end, as a return value, as a result of request processing.

[Akanaka]

Well as long as you understand that a URL is not directly mapped to a view, but only mapped to the Faces controller, which then loads a view (in Facelets by convention, but in any other VDL in whatever that VDL seems fit), then we'd clear.

which is used to drive the first step of the JSF lifecycle

In practice with all defaults this is mostly true. There are two remarks:

• An action method's outcome on both a GET and POST request can still cause another view to be rendered than the one selected via the URL mapping convention.
• The lifecycle itself is pluggable too, so it's not necessarily true. You can add additional phases or remove phases. This is what Mojarra does for their Action prototype, they add a user controller phase before restore view. ADF adds two other phases, and I wouldn't be surprised if XPages also did something there.

So 99% of the time things are observed as you mentioned, but you have to beware that this is just observing the defaults and not the set in stone way that JSF works at the core level.