I havent used JSF before, nor have i tried my hands at SEAM yet. As per Gavin, one of the reasons (or i guess the primary reason) why SEAM was started was :
Seam was born out of our frustration with the limitations of todays stateless application architectures (stateless session facade, Spring, RoR, etc), which do not include constructs for modeling optimistic transactions, and therefore cause all kinds of problems for Hibernate users (LazyInitializationException and his friends).
My question is why was JSF singled out or rather chosen for SEAM? The LazyInitializationException and the stateless architecture was common in other application too (for example application using Struts). [ June 05, 2007: Message edited by: Jaikiran Pai ]
I think of the biggest point is that Seam is there to fill in the gap that is missing in Java EE 5. And JSF and EJB3 are all standards and part of that spec, which is most likely why those are used.
When starting Seam, we actually looked around at the various web frameworks. JSF was ultimately chosen because:
It is a standard. It has an extremely powerful and flexible request/response model that provides what we need for complex features like conversations and intelligently-managed persistence/tx It supports a component-based development model. Not only is it simpler and more powerful than action-based frameworks, it has a lot of potential for tooling.
However, Seam really doesn't have to use JSF. It's entirely possible for someone to decide they would rather use a different web framework and to write the integration bits for that framework. I don't foresee that happening because JSF turns out to work really well in practice, at least in the context of Seam where we have already taken the rough edges out.
0
