The front page of this site has a section Reinvesting in Java EE.

I like Seam a lot. But I find I can do everything with JPA and POJO components.

Need a conversation scoped component? What's wrong with @Name combined with @Scope(ScopeType.CONVERSATION) on a plain POJO, instead of a stateful SSB?

Need some stateless logic? Why do @Stateless instead of @Name and @Scope(ScopeType.STATELESS) on a plain POJO?

In the documentation, I could only spot:

Javabeans may be used just like a stateless or stateful session bean. However, they do not provide the functionality of a session bean (declarative transaction demarcation, declarative security, efficient clustered state replication, EJB 3.0 persistence, timeout methods, etc).

Ok, I admit: I use JPA entities. But that's all. So what's left? Transactions? The same document then goes on to debunk these explaining that seam-managed transactions are much more convenient AND efficient than J2EE:

If you're using Seam outside of a Java EE 5 environment, you can't rely upon the container to manage the persistence context lifecycle for you. Even if you are in an EE 5 environment, you might have a complex application with many loosly coupled components that collaborate together in the scope of a single conversation, and in this case you might find that propagation of the persistence context between component is tricky and error-prone.

In either case, you'll need to use a managed persistence context (for JPA) or a managed session (for Hibernate) in your components. A Seam-managed persistence context is just a built-in Seam component that manages an instance of EntityManager or Session in the conversation context. You can inject it with @In.

Seam-managed persistence contexts are extremely efficient in a clustered environment. Seam is able to perform an optimization that EJB 3.0 specification does not allow containers to use for container-managed extended persistence contexts. Seam supports transparent failover of extended persisence contexts, without the need to replicate any persistence context state between nodes. (We hope to fix this oversight in the next revision of the EJB spec.)