File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes Why JSF for SEAM? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Why JSF for SEAM?" Watch "Why JSF for SEAM?" New topic

Why JSF for SEAM?

Jaikiran Pai

Joined: Jul 20, 2005
Posts: 10441


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).

- Quote taken from here

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 ]

[My Blog] [JavaRanch Journal]
Mark Spritzler

Joined: Feb 05, 2001
Posts: 17276

Funny you should ask this question.

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.


Perfect World Programming, LLC - iOS Apps
How to Ask Questions the Smart Way FAQ
Jaikiran Pai

Joined: Jul 20, 2005
Posts: 10441

And JSF and EJB3 are all standards and part of that spec

Ahhh... I didnt know JSF was part of the spec. Now that explains why SEAM uses JSF. Thanks Mark
norman richards
Ranch Hand

Joined: Jul 21, 2003
Posts: 367
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.
I agree. Here's the link:
subject: Why JSF for SEAM?
It's not a secret anymore!