This feature has been present in 3.0 already but hasn’t been officially mentioned before. It enables you to configure JSF plugins ( ViewHandler , NavigationHandler etc.) and components ( Converter , UIComponent etc.) using Spring with all of it’s configuration facilities. In 4.0, we’ve implemented this feature using Spring’s namespace handlers, making the development easier for us while reducing the error proneness for the application developer.

In most navigation cases, it isn't really necessary to transfer the full state of the component tree because it doesn't change between requests. For those cases, it's now possible to turn off state saving by using specific JSF-Spring-Forms. The component tree will be rebuilt from scratch for each request. This feature requires the use of Facelets, though, since we aren't able to restore the UIViewRoot without it. Using JSF-Spring's tree management, you can cut down page and session sizes dramatically.

On top of that, JSF-Spring now provides forms that issue GET requests which will run through JSF’s lifecycle. They don’t carry the full state, either, since this usually is way too big for URL parameters. By including inputs whithin the form, you’re able to selectively maintain the state between requests. These values are still being applied according to their value bindings during the apply request values phase . The main purpose of this feature is to provide you with GET requests where the HTTP and the REST model propose to do so, namely for non-data-changing purposes, e.g. search requests. As a side effect, browser back button issues can be reduced if not avoided at all.

You are now able to integrate any kind of controller into JSF’s lifecycle. This can be a Spring controller bean, a struts action or whatever SpringMVC is able to handle. The controller is being mapped using URLs just like in SpringMVC, but it is being executed within JSF’s lifecycle, extending the invoke application phase. All the other phases are being run, so you're able to benefit from JSF’s conversion/validation features and use value and method bindings while still being able to map actions to distinct URLs. A side benefit of this is that it’s a lot easier now to secure your web application using Spring Security (Acegi Security). Furthermore, forms being sent to such actions can be sent without using JavaScript – much unlike common JSF forms.