Re: [weld-dev] persistence and transactions outside Java EE

One of the main issues I had with Seam 2.x was the (lack of) tx propagation support options (specifically REQUIRES_NEW and NOT_SUPPORTED) when using @Transactional when compared with EJB3 tx support and Spring tx support. Refer to this thread: http://sfwk.org/Community/TransactionalPropagationTypes and this: https://jira.jboss.org/jira/browse/JBSEAM-595 and this: https://jira.jboss.org/jira/browse/JBSEAM-4391 AFAIK this is not fixed and/or released.  Will this be fixed and released with Seam3? On Tue, Nov 24, 2009 at 12:44 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > > 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 > > On Tue, Nov 24, 2009 at 3:41 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: >> >>> >>> 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 > > > > -- > 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 > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev