Most of my webapps these days are Spring+JSF. Spring handles the persistency layer as well as various other plug-in services (such as for example, mailing, where I employ a dummy mailer for testing).
JSF also does dependency injection. My recommendation on security is that the primary security provider be J2EE container security, which you can then build on, as needed. I've see one or 2 mainstream webapps that use that technique for the coarse-grained security plus Spring security for the fined-grained stuff and it works well for them.
The primary reason for using both platforms is that while Spring excels at general-purpose java needs, JSF has more power in the specific area of MVC-based web GUI support. Since they play well together, I get the best of both.
An IDE is no substitute for an Intelligent Developer.
Joined: Apr 30, 2002
Thanks Tim for your response.
Just wondering what is your preference for component management, JSF managed beans or Spring? I personally feel the Spring container is better at managing my beans so I just add...
I use JSF for the MVC Models and Spring for the other stuff and use the resolver to ensure that they're all in the same namespace.
Spring beans are typically singletons, existing for the lifespan of the application. The J2EE equivalent would be (roughly) Application Scope. However, most of what I need for UI models is Session, View, or (rarely) Request scope. JSF is better for that, since it's wired into the MVC framework and can instantiate those objects on-demand. And, in the case of View scope, destroy them as well.
So my View templates are almost exclusively referencing JSF Managed Beans. The Managed beans get both other Managed Beans and Spring Beans injected into them. The persistence interfaces are Spring - as are other non-GUI singleton objects. The View-to-View data exchange is JSF.
The lines are gradually blurring as we move to a more unified model of bean control (CDI), but that's how I'm currently doing it.