JavaServer Faces (JSF2) and JAX-RS don't play well together

I've been working with JavaServer Faces 2 (JSF2) since shortly after its release, and it continues to be an annoying mix of excellent and frustrating to work with. It's theoretically a great technology, especially with CDI (contexts and dependency injection) even despite the holes and quirks in the spec. There are just two wee problems.

First, unlike many of the other EE specs, the JSF2 spec really isn't written to be useful for developers intending to use JSF2 in their apps. It's very much a specification not a reference, and I found it hard to read even as a specification. Because I was getting started with JSF2 in the very early days of EE 6, I seem to remember that the now very helpful Java EE Tutorial wasn't EE6 ready yet or was incomplete, so I didn't have that as a basis for learning JSF2 and EE6 either. Perhaps my memory is just failing me. In any case, I often landed up stumbling through Google-land trying to find out details that I thought should be obvious and easy to find in the spec or other reference documentation. At the time, Google-land was full of outdated references to JSF 1, lots of migration guides from Spring to EE 6, and plenty of other things to side-track a confused newbie. All in all, it was really hard to get going with JSF2 alone.

Second, the JSF2 spec was clearly concocted with no thought of or co-operation with the JAX-RS spec, and it shows. They don't work well together, and it's really, really frustrating because they should be so useful in combination.

Edit: Part of the issue here appears to be that I was trying to use JSF2 just for the Facelets templating language, expecting to be able to interoperate with JAX-RS where possible. JSF2 is a framework and doesn't isn't really designed to enable you to easily step outside the abstractions imposed by the framework - not least because you shouldn't need to. I was probably going about this the wrong way in a square-peg, round-hole kind of way, and shouldn't have been trying to use JSF2 in the first place. That's not made particularly obvious by the docs, though.

Documentation

How do you insert the context path of your servlet into the page? The answer is to use the contextPath property of the implicit request property - but good luck finding that out unless you already know about it, or you've somehow managed to wade through the JSF 2.0 spec to find it. I was using FacesContext to obtain it via a very roundabout route before I finally found out about the implicit request object. There's plenty of information about the pageContext object from the older JSP standard, but that's defunct in JSF2.

Reading this might help you with JSF implicit variables. I wouldn't recommend trying to read the JSF2 spec its self as a reference and learning aid, though, it's really focused on spec implementers and isn't especially accessible to JSF2/facelets users. This one, at least.

JSF2 doesn't mesh well with JAX-RS

The other thing that's increasingly frustrating is the mismatch between JAX-RS (Jersey etc) and JSF2. They have different injection points in different lifecycles, making it hard to make a single class cleanly handle both JSF2 and JAX-RS requests. For example, if your method needs access to the HttpServletRequest, in JAX-RS you add a @Context HttpServletRequest request method parameter, which JAX-RS will automagically pass when calling your method. In JSF2 you access it via (HttpServletRequest)FacesContext.getInitialContext().getExternalContext().getRequest(). These two mechanisms are incompatible, and mean that you have to write two wrapper methods to call the same underlying code depending on how the call came in. Needless to say, that's annoying - and it's enshrined in the JAX-RS and JSF2 specs.

While you can call the JAX-RS method using EL method calls like ${myClass.myMethod(request)} you can't use that as a writable EL property. You land up writing SIX methods (JSF2 getter, JSF2 setter, JAX-RS getter, JAX-RS setter, private impl getter, private impl setter) instead of just annotating the two real implementation methods and letting injection take care of it.

Instead of something like the (non-working) code:

@Named
@Path("/test")
@RequestScoped
public class Something {

  @Inject private HttpServletRequest currentRequest;

  @Path("/property")
  @Produces("text/plain")
  public String getProperty() {
    // do the work here
  }

};

we land up writing something like:

@Named
@Path("/test")
@RequestScoped
public class Something {

  @Path("/property")
  @Produces("text/plain")
  public String getPropertyJAXRS(@Context HttpServletRequest request) {
    return getPropertyImpl(request);
  }

  public String getProperty() {
  getPropertyImpl((HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest());
  }

  private String getPropertyImpl(HttpServletRequest request) {
    // Do the work here
  }

};

This might be fixable with a CDI extension to provide consistent injection of things like the HttpServletRequest, but Seam Servlet (which should theoretically do it) fails to deploy to Glassfish with an NPE. Yay!

Of course, someone will chime up and say "you shouldn't need to do that, stay within the framework". Unfortunately web frameworks like JSF2 have large feature holes that sometimes force you to go to a lower level, especially if you need to inter-operate with other tools or frameworks. How do you get to the application's initial context parameters via facelets-only or jax-rs-only API, for example? You can't, you need to access the ServletContext to do that. How do you accept a multipart/mixed file upload with JSF2? Or exchange JSON data with a client?

Another problem is the difficulty of accessing the JSF2 context to do things like map outcomes to URLs from JAX-RS methods when you want to do something like send a redirect from a JAX-RS POST request to a JSF2 page.

Results

The end result is that whenever I need to add web services capabilities to my beans, I land up converting them to pure JAX-RS beans and converting my JSF2 xhtml across to plain XHTML+JavaScript with JQuery. So much pain just goes away when I'm not trying to mix both systems.