Great work, thanks Stuart. I was wondering about one thing though - why is @Transactional not an interceptor binding? The way it is now, you can't use it in a stereotype (though you can probably use @TransactionalInterceptorBinding, but this is in the impl module not the api, and having to use it instead of @Transactional seems inconsistent). Shane On 15/10/10 09:05, Stuart Douglas wrote: > I just though I would send out a quick overview of exactly what is in > the persistence module at the moment: > > > Transactions: > > It provides a SeamUserTransaction object that extends the JTA > UserTransaction (this means a dependency on the jta API). > > Three default implementations will be provided > - The default EE version that either looks up UserTransaction in JNDI > or retrieves it from the EJBContext if a CMT is active > - An implementation that uses EntityTransaction, this is retrieved from the SMPC > - An implementation that uses hibernate's transaction API (to be done) > > It does not use the CDI's ability to inject the UserTransaction for a > number of reason: > - It is not available in all environments > - It is not available in EJB's that use CMT > > It provides a transaction interceptor, this allows you to use > @TransactionAttribute on managed beans the same way you would on > EJB's. > It provides @Transactional and @SeamApplicationException for > environments where these API's are not available. > > Managed Persistence Contexts > > - Defined as follows: > > @SeamManaged > @Produces > @ConversationScoped > @PersistenceUnit("myPu") > EntityManagerFactory enf; > > - This will work even in environments where @PersistenceUnit injection > is not directly supported, as seam-persistence will bootstrap it for > you. > > - The SMPC provides the following: > - Automatic transaction enlistment > - Ability to use EL in queries > - Automatic hibernate search integration, if available > - Ability to set manual flush mode if required > - Event is fired when the SMPC is created, to allow for additional > configuration such as adding hibernate filters. > > It also provides @TransactionScoped for transaction scoped beans > (forgot to put this in the reference guide, oops) > > There are currently tests for jboss-as, jetty, and jetty+openjpa (with > no hibernate classes present on the classpath). I am planning on also > adding glassfish, glassfish+hibernate, and probably a few more as > well. > > I have also added seam managed transactions to the faces module, this > is similar to seam 2, however it has two notable improvements: > - It can be controlled on per view basis (including using wildcards) > - it can be enabled only for the RENDER_RESPONSE, so you have manual > transaction control in your business logic, and then seam opens a > transaction for you when rendering to prevent LIE's (this also can be > configured on a per view basis). > > I think that just about covers it. If anyone has any questions or > comments fire away. > > Stuart > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

That is a good question. Currently the CDI specification does not allow interceptors on the methods level to override interceptors on the field level (I have

filed an issue for this), if @Transactional was an interceptor binding it would not be possible to override the behaviour of individual methods. Also it is not really desirable to make @TransactionAttribute an interceptor binding, and I think we should prefer @TransactionAttribute where possible, just so there is only one annotation users need to remember. Good point about the stereotype's though. I might add some trickery to the transaction extension to deal with this. Stuart On Fri, Oct 15, 2010 at 10:56 AM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: >  Great work, thanks Stuart. > > I was wondering about one thing though - why is @Transactional not an > interceptor binding?  The way it is now, you can't use it in a stereotype > (though you can probably use @TransactionalInterceptorBinding, but this is > in the impl module not the api, and having to use it instead of > @Transactional seems inconsistent). > > Shane > > On 15/10/10 09:05, Stuart Douglas wrote: >> >> I just though I would send out a quick overview of exactly what is in >> the persistence module at the moment: >> >> >> Transactions: >> >> It provides a SeamUserTransaction object that extends the JTA >> UserTransaction (this means a dependency on the jta API). >> >> Three default implementations will be provided >> - The default EE version that either looks up UserTransaction in JNDI >> or retrieves it from the EJBContext if a CMT is active >> - An implementation that uses EntityTransaction, this is retrieved from >> the SMPC >> - An implementation that uses hibernate's transaction API (to be done) >> >> It does not use the CDI's ability to inject the UserTransaction for a >> number of reason: >> - It is not available in all environments >> - It is not available in EJB's that use CMT >> >> It provides a transaction interceptor, this allows you to use >> @TransactionAttribute on managed beans the same way you would on >> EJB's. >> It provides @Transactional and @SeamApplicationException for >> environments where these API's are not available. >> >> Managed Persistence Contexts >> >> - Defined as follows: >> >> @SeamManaged >> @Produces >> @ConversationScoped >> @PersistenceUnit("myPu") >> EntityManagerFactory enf; >> >> - This will work even in environments where @PersistenceUnit injection >> is not directly supported, as seam-persistence will bootstrap it for >> you. >> >> - The SMPC provides the following: >> - Automatic transaction enlistment >> - Ability to use EL in queries >> - Automatic hibernate search integration, if available >> - Ability to set manual flush mode if required >> - Event is fired when the SMPC is created, to allow for additional >> configuration such as adding hibernate filters. >> >> It also provides @TransactionScoped for transaction scoped beans >> (forgot to put this in the reference guide, oops) >> >> There are currently tests for jboss-as, jetty, and jetty+openjpa (with >> no hibernate classes present on the classpath). I am planning on also >> adding glassfish, glassfish+hibernate, and probably a few more as >> well. >> >> I have also added seam managed transactions to the faces module, this >> is similar to seam 2, however it has two notable improvements: >> - It can be controlled on per view basis (including using wildcards) >> - it can be enabled only for the RENDER_RESPONSE, so you have manual >> transaction control in your business logic, and then seam opens a >> transaction for you when rendering to prevent LIE's (this also can be >> configured on a per view basis). >> >> I think that just about covers it. If anyone has any questions or >> comments fire away. >> >> Stuart >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > >

Stuart, I don't know if these issue is part of the "Persistence Module" or not, but what IMHO is important is that Seam 3 plays nicely with the "User Transaction" (UT) and the JNDI space where the UT is looked up. The JEE 5 specification defines usually when and where the JNDI namespace for UT is available or not. For example, there is no guarantee to have access to a viable JNDI space and so to get a UT in session listeners or in "secondary" threads like the one started by quartz for example. In Seam 2 (but also in other frameworks that abstract those objects) there are lots of "workarounds" or "empty catch blocks" to handle the situation. I have now in mind the code added (I commit some) to address the case of session listeners that tries to perform a lookup for UT and play (ie commit/rollback) with it when a session closes. JEE 5 does not guarantee that such objects are available in such contexts. This has always been a problem with AS that (more) strictly enforce this, like WebSphere v6.x and WebSphere 7. I know that JNDI specs changed in JEE6 (but not JTA) but I don't know if things changed regarding the availability of a JNDI name space "everywhere" and also to have acces to a valid "UT" "everywhere", or at least in any place Seam will need it. I don't know if there are "easy" solutions for this problem but at least this should be adress as nicely as possible, and I hope JEE 6 solved some of those problems. When the persistence module and Seam 3 will be available in some "testable" state, I'll test them on WebSphere 8 (still in beta for now). Denis. On 10/14/2010 08:44 PM, Stuart Douglas wrote: > On Fri, Oct 15, 2010 at 11:17 AM, Stuart Douglas > <stuart.w.douglas(a)gmail.com&gt; wrote: >> That is a good question. >> >> Currently the CDI specification does not allow interceptors on the >> methods level to override interceptors on the field level (I have > That should be bean level, not field level. > > Stuart > >> filed an issue for this), if @Transactional was an interceptor binding >> it would not be possible to override the behaviour of individual >> methods. Also it is not really desirable to make @TransactionAttribute >> an interceptor binding, and I think we should prefer >> @TransactionAttribute where possible, just so there is only one >> annotation users need to remember. >> >> Good point about the stereotype's though. I might add some trickery to >> the transaction extension to deal with this. >> >> Stuart >> >> On Fri, Oct 15, 2010 at 10:56 AM, Shane Bryzak&lt;sbryzak(a)redhat.com&gt; wrote: >>> Great work, thanks Stuart. >>> >>> I was wondering about one thing though - why is @Transactional not an >>> interceptor binding? The way it is now, you can't use it in a stereotype >>> (though you can probably use @TransactionalInterceptorBinding, but this is >>> in the impl module not the api, and having to use it instead of >>> @Transactional seems inconsistent). >>> >>> Shane >>> >>> On 15/10/10 09:05, Stuart Douglas wrote: >>>> I just though I would send out a quick overview of exactly what is in >>>> the persistence module at the moment: >>>> >>>> >>>> Transactions: >>>> >>>> It provides a SeamUserTransaction object that extends the JTA >>>> UserTransaction (this means a dependency on the jta API). >>>> >>>> Three default implementations will be provided >>>> - The default EE version that either looks up UserTransaction in JNDI >>>> or retrieves it from the EJBContext if a CMT is active >>>> - An implementation that uses EntityTransaction, this is retrieved from >>>> the SMPC >>>> - An implementation that uses hibernate's transaction API (to be done) >>>> >>>> It does not use the CDI's ability to inject the UserTransaction for a >>>> number of reason: >>>> - It is not available in all environments >>>> - It is not available in EJB's that use CMT >>>> >>>> It provides a transaction interceptor, this allows you to use >>>> @TransactionAttribute on managed beans the same way you would on >>>> EJB's. >>>> It provides @Transactional and @SeamApplicationException for >>>> environments where these API's are not available. >>>> >>>> Managed Persistence Contexts >>>> >>>> - Defined as follows: >>>> >>>> @SeamManaged >>>> @Produces >>>> @ConversationScoped >>>> @PersistenceUnit("myPu") >>>> EntityManagerFactory enf; >>>> >>>> - This will work even in environments where @PersistenceUnit injection >>>> is not directly supported, as seam-persistence will bootstrap it for >>>> you. >>>> >>>> - The SMPC provides the following: >>>> - Automatic transaction enlistment >>>> - Ability to use EL in queries >>>> - Automatic hibernate search integration, if available >>>> - Ability to set manual flush mode if required >>>> - Event is fired when the SMPC is created, to allow for additional >>>> configuration such as adding hibernate filters. >>>> >>>> It also provides @TransactionScoped for transaction scoped beans >>>> (forgot to put this in the reference guide, oops) >>>> >>>> There are currently tests for jboss-as, jetty, and jetty+openjpa (with >>>> no hibernate classes present on the classpath). I am planning on also >>>> adding glassfish, glassfish+hibernate, and probably a few more as >>>> well. >>>> >>>> I have also added seam managed transactions to the faces module, this >>>> is similar to seam 2, however it has two notable improvements: >>>> - It can be controlled on per view basis (including using wildcards) >>>> - it can be enabled only for the RENDER_RESPONSE, so you have manual >>>> transaction control in your business logic, and then seam opens a >>>> transaction for you when rendering to prevent LIE's (this also can be >>>> configured on a per view basis). >>>> >>>> I think that just about covers it. If anyone has any questions or >>>> comments fire away. >>>> >>>> Stuart >>>> _______________________________________________ >>>> seam-dev mailing list >>>> seam-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev