[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=all ] Michael Youngstrom updated JBSEAM-1144: --------------------------------------- Attachment: seam-tx-2.zip Here is a second try at a Transaction component. I added a JpaTransaction components and it appears to work great with the jpa booking example removing any dependence on a JTA implementation. To enable this I had to do a little more moving fanagling of SeamPhaseListener. I ended up putting SeamPhaseListener back the way it is in CVS and changed TransactionalSeamPhaseListener to start a transaction AFTER restore view instead of BEFORE restore view. I don't think this will cause many problems since a Seam Conversation scoped persistence context won't even be available during before restore view. And it hasn't appeared to effect anything in the booking example. I included entire instances of the heavily changed files for easier review in this bundle. Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358886 ] Christian Bauer commented on JBSEAM-1144: ----------------------------------------- You can use any JTA runtime. This is an open standard. I am very much against this extension, adding proprietary transaction interfaces was a major mistake with Hibernate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358891 ] Michael Youngstrom commented on JBSEAM-1144: -------------------------------------------- I agree we don't want to provide another transaction interface that is why this patch does not introduce a new proprietary interface. It simply provides an implementation of UserTransaction. Seam already is dependent upon 2 Tx APIs JTA and EjbContext (container managed tx). All this patch does is combine the 2 apis into a single implementation of UserTransaction and exposes it as a Seam Component. I did add a utility flag "isJoinable" but that is it. :) I agree that JTA is a fine tx api. However, the biggest problem I have with the strict use of JTA in Seam it's dependence on JNDI. There may be many great JTA runtimes available but they become a beast (with the exception of microcontainer) to configure when it comes to trying to correctly expose them with JNDI not to mention your datasources that must be wrapped and exposed through JNDI as well. As a side effect because seam components are overridable it allows for wrapping of other transaction APIs or even easier wrapping of other JTA implementations without the dependence on JNDI. I think this patch provides the added benefits helping make seam applications more lightweight, more portable, easier to configure, less thirdparty layers between code and database, and less dependencies for projects who want to deploy on a simple web container. And does it all without providing any new Transaction interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358911 ] Christian Bauer commented on JBSEAM-1144: ----------------------------------------- "However, the biggest problem I have with the strict use of JTA in Seam it's dependence on JNDI. There may be many great JTA runtimes available but they become a beast (with the exception of microcontainer) to configure when it comes to trying to correctly expose them with JNDI not to mention your datasources that must be wrapped and exposed through JNDI as well. " Then let's fix that. We should _not_ wrap a standard API. The "benefits" you list are all just nice words, wrapping does not make things more portable (if what you wrap is by definition already an interface), more lightweight (what does that mean?), easier to configure (making JTA providers easier to configure makes stuff easier to configure) and it does reduce dependencies (on what? jta-api.jar?) Folks, it is time to put more pressure on vendors who provide JTA services. They need to make their stuff easier to setup and use. The solution is not another layer of transaction wrapping in Seam, you end up with an horrendous stack that you will _never_ be able to deprecate. And there is no such thing as "applications that don't need JTA". Seriously, realize that this is the standard interface in Java! What else do you want to use? JDBC? EntityTransaction? Spring magic? If you want to set transaction boundaries, you do this with JTA or you have a container that understands @TransactionAttribute. I even think the addition of @Transactional in Seam was a serious mistake and I don't know why Gavin (who does know better) added it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358946 ] Michael Youngstrom commented on JBSEAM-1144: -------------------------------------------- I don't think you read what I said before. This transaction component IMPLEMENTS UserTransaction and nothing else. It does not provide a new Transaction interface. "And it should be obvious that the "natural migration path" is _away_ from proprietary (Spring, org.hibernate.Transaction) and useless (javax.persistence.EntityTransaction) APIs _towards_ a standard API (javax.transaction.UserTransaction)." I agree. And I think this patch is a great avenue towards that migration path. The seam component implements UserTransaction. So the migration path is clear. Provide a standard JTA/EJB implementation like we have and like what util.Transactions was doing but in a cleaner way. Optionally provide other component implementations which expose EntityTransaction and org.hibernate.Transaction as UserTransaction instances. You get everyone to migrate off of their resource local transaction interfaces and onto JTA's UserTransaction. Then when JTA becomes more prevalent, is improved, or becomes easier to configure, etc. We simply remove the other transaction component implementations and everyone is now using standard JTA with the UserTransaction interface. No interfaces to deprecate because everyone was using UserTransaction from the beginning. One other thought, everything else in Seam is a component what makes JTA so different that it cannot be exposed as a component as well? Making transaction management a component helps to clean up other things in seam too such as: Being able to set a custom userTransactionName on the actual Transaction Component instead of using init and storing it in a static field. Giving people the option to "turn off" transaction management in seam. Maybe they have no need to hit a database. Seam allows you to simply not install a component in a standard way. Seam can now take advantage of that standard functionality in places like ExceptionFilter and TransactionInterceptor. In the case of ExceptionFilter you can now have a clear and Seam standard way to determine if Seam is providing Transaction support or not. If it is it can rollback the transaction if not it won't even try. In the case of TransactionInterceptor you now have a simple standard way to determine if Transaction support is installed in Seam or not so you can now show the user a nice error message if they try to use Transaction support when it is not installed. What can be wrong with exposing transactions in seam the same way everything else in Seam is exposed? Without creating any new Interfaces and providing a clear migration path to JTA for those not currently using JTA? Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358953 ] Mike Heath commented on JBSEAM-1144: ------------------------------------ I think in an ideal world, having only JTA would be fine. We don't live in an ideal world and for better or for worse, there are those of us who have a legacy that requires us to use a transaction manager that does not implement JTA. The approach Mike Youngstrom is taking doesn't move away from JTA and still allows us to use our legacy code with Seam. I understand the point of pressuring vendors to standardize on JTA. Standards are a good thing. Pressuring vendors to use a standard is a good thing. However, even if all the vendors change, that won't rewrite all the legacy code we have the depends on Spring's transaction manager. I'm sure we're not the only Java shop on the planet with this issue. I'm also having a hard time understanding why you would not want to make the transaction manager a component like everything else in Seam. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12359040 ] Christian Bauer commented on JBSEAM-1144: ----------------------------------------- There are two sides to this: - I have nothing against exposing the transaction service as a Seam component if that is what fits best into the overall architecture. Whatever makes the system more cohesive is fine. - How will users perceive and use this extension (independent from how it's implemented) and what are the long term effects. They will continue using whatever legacy code they have. Our component will wrap it. There is no migration path because we do everything for them, wrap and hide their legacy code. They will not realize that they should use JTA - from a users perspective everything works fine. They will start new projects using org.hibernate.Transaction and Spring transaction management. The JTA vendors will not realize their stuff should be made easier to use because nobody is using it. You will never be able to remove these components. The time is _now_ to break this circle, we only get a chance like this every 5 years. Michael, note that I am not saying that we should not implement what you have done, it will certainly be integrated into Seam. The question is how we communicate it to users. IMO it should be hidden as good as possible behind a "migrate to JTA" manual. But, from experience I know that if we all forget to agree on this at this stage, it will not happen and the wrapper will just creep into the documentation with the negative effects I describe. Btw, some colleagues are currently working on an extension to the main Hibernate tutorial that describes how to install JBoss TS with JTA, right after Hello World. The overview for the other JTA providers posted yesterday on the forum is also a great resource we need to leverage for this kind of documentation. Let's do what we can on this front before this component is committed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=all ] Michael Youngstrom updated JBSEAM-1144: --------------------------------------- Attachment: seam-tx-3.zip I've posted my third and final candidate patch. Although I would still prefer something more like patch 2. I think something like this patch is a good mix between what I would like to see and what Christian wouldn't mind seeing. :) I created a single Transaction component. That @UnWrap to a UserTransaction. The UserTransaction implemented in Transaction provides a mix of handling JTA transactions and EjbContext (container managed) transactions. People who wish to do programmatic transaction management can safely biject this transaction component. This Component also allows user to disable seam managed transactions by simply uninstalling this component (it's installed by default). I've updated dependencies on this component to function correctly if seam managed transactions are not installed. I've also added a "userTransaction" attribute to the component to allow users to inject a UserTransaction expression instead of using jndi if a jndi managed UserTransaction is not available. Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=all ] Gavin King updated JBSEAM-1144: ------------------------------- Fix Version/s: 1.3.1.BETA1 (was: 1.3.0.ALPHA) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=all ] Gavin King closed JBSEAM-1144. ------------------------------ Resolution: Done Thanks, I applied your patch (with some changes), which was really excellent work. This is a much more elegant design. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12363595 ] Michael Youngstrom commented on JBSEAM-1144: -------------------------------------------- I would have deleted the other ones if I could. :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12363634 ] Michael Youngstrom commented on JBSEAM-1144: -------------------------------------------- What you checked in paves the way for all the functionality I wanted. Looks good. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira