1. A short history of JSF-Spring

JSF-Spring started out as an integration library for JavaServer Faces and the Spring framework . For integration purposes, Spring itself provides the DelegatingVariableResolver . With it, you can reach Spring managed beans from JSF's managed-beans and connect them via dependency injection. JSF-Spring went one step further by implementing a VariableResolver that was built onto a Spring context and thus activated all bean-related features of Spring for JSF managed beans, too.

Since the release of Spring 2.0, in most cases it won't be necessary anymore to use managed-beans at all: The main advantage of them was the possibility to scope them to requests and sessions, which is now also possible for Spring beans. By defining all beans in Spring contexts, you can now maintain a clear separation of concerns: The complete application code is being handled by Spring, while JSF is being used for data presentation and user interaction. This way, both frameworks will do what they are best at.

Because of this development, the sheer integration of JSF and Spring isn't the main task for JSF-Spring anymore. With the release of version 4.0, we're heading in the direction of providing an extension library that simplifies the development of web application. While all integration features of JSF-Spring are still in place and can be used as in former versions, the main goal of JSF-Spring 4.0 is to make the JSF specification more usable for the development of “ordinary” web applications by utilizing Spring features.

2. Release objectives for JSF-Spring 4.0

In our JSF projects, we’ve been greatly disappointed by two factors: the lack of “webness” , given the fact that everything is a POST and the dependency to JavaScript, and the often cumbersome JSF specification. On the other hand, features like the standard request lifecycle and form validation proved to be very useful.

The new features in JSF-Spring 4.0 are our attempt to enable developers to take advantage of JSF as a component based framework on the one hand but still deliver applications that conform to well established web standards on the other: To the HTT protocol with it's Noun/Verb model and the resulting REST model for web applications (see e.g. ).

We’re very excited about that perspective and we hope you’ll share our enthusiasm!