Btw, this is exactly why most people use Seam 2. They don't want to deal with EJB. They can just annotate with @Name and inject a Seam-managed persistence context. The transactions are hooked into whatever they want: local, JTA or Spring. It's "the hell with EJB" approach.
I'm just saying perhaps we can find a way to cater to this approach in Java EE so we don't lose those people to the platform.
-Dan
It's somewhat related....in terms of Resin, we actually don't have such
a thing as a traditional EJB container - we have "aspects" such as
transactions delivered via meta-data (e.g. @TransactionAttribute), the
aspects are bound to an underlying implementation (e.g. transaction
manager) and can be used in any component model including managed beans
or EJB. The "EJB Lite" distinction is tenuous since you don't really
need to use the EJB component model per se.
To be honest, I'm kind of confused myself now. Circling back to my initial argument, the two options we provide in Java EE at this moment are:
- a non-transactional "simple" managed bean or,
- an EJB session bean (which is, by default, transactional, and more)
So if the developer wants a transactional bean without using an EJB container, they have to use some sort of framework (or portable CDI extension) to get it. To me, that is where Java EE falls apart. There needs to be some middle of the road that the developer can get a transactional bean out of the box OR we just need to say, if you want a transactional bean, you have to use EJB w/ at least EJB lite, period.
Why isn't the "simple" transactional bean something that Java EE can provide. Clearly a use case is being ignored.
-Dan
p.s. The "simple" transactional bean would be a bean w/ @TransactionAttribute and somehow @PersistenceContext would be supported on the bean.
--Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen