Integrating Spring & JavaServer Faces : MVC Nuts and Bolts

I have attempted to integrate JSF with Spring MVC in the past, and whilst my first attempt worked, it was far from ideal.  This time around I decided to take a few key decisions to help focus my efforts:

• Drop backwards compatibility.  There is just too much work involved with supporting JSF 1.2 and too much good stuff coming up in Spring 3.1 to ignore.
• MVC annotations are king.  @RequestMapping seems to be the preferred approach for most people; lets only support this and keep any custom annotations to a minimum.
• Reduce dependencies.  It’s nice to reuse stuff but this is an integration project so the less there is to integrate the better.

With this in mind I decided to take the org.springframework.faces.mvc.JsfView class from Web Flow as my inspiration.  This class works really well because it only deals with the View in MVC, the Model and Controller remain entirely in the realm of Spring.   The only problem with JsfView is the lack of postback support.  We need to somehow detect the difference between the initial request for a view and any subsequent JSF postback.

Thanks to Spring MVC having a very flexible architecture this is entirely possible.  We can have multiple HandlerMapping and HandlerAdapter beans registered with the DispatcherServlet.  To support JSF we need something high up in this chain that can detect and deal with  postbacks, leaving anything that is not a postback to be dealt with in the usual way.  Here is the general sequence of events:

user               dispatcher    @controller
 |  /some/request      |              |
 |-------------------->|   maps to    |
 |                     |------------->|  creates
 |                     |              |------------> FacesView
 |                     |                             (/pages/file.xhtml)
 |                     |   render                        |
 |                     |-------------------------------->|
 |                     |                           [Delegate to JSF]
 |  response           |<--------------------------------|
 |<--------------------|
 |                     |
 |                     |
 | /some/request       |
 | (postback)          |
 |-------------------->|      postback handler
 |                     |--------->|
 |                     |    [Delegate to JSF]
 |  response           |<---------|
 |<--------------------|          |
 |                     |          |

 
The postback handler has a couple of interesting problems to deal with.  1) How do we know we are a postback.  2) How do we know what view to restore.  Obviously a postback will be a HTTP POST operation, but we cannot blindly assume that all POSTs are JSF postbacks.  We also need to know what XHTML file to restore, but this file is based on a decision taken by the @Controller of the last request.

The answer to both these problems is to write our own JSF ResponseStateManager.  The ResponseStateManager is part of JSFs state management infrastructure and is responsible for reading and writing component state.  Usually JSF will save the state data in the HTTP session and write a hidden form field within the page so it can be restored later.  Hooking into this mechanism we can write an additional field for MVC, the presence of the field lets us know that we have a postback and furthermore the value will let us know what XHTML file to restore.

With the postback handler in place we now have the best of both the Spring and JSF worlds.  We can use @RequestMapping annotations to build expressive URLs and JSF components to render complex web pages.  If want to we can even return different Views for the same URL based on entirely different technologies (for example by inspecting the HTTP header we might decide to return a JSF page or a XML document).

If you want to look at postback handler code it is available here.  The usual caveats of this being a moving codebase apply.