One thing I'd ask for future is that you stick to hibernate style as it makes it easier to see *real* changes. For example, you are using space-expansion in place of tabs, etc.
This discussion has come up before and I had been thinking of another approach to address this, however, my approach is more disruptive. Basically, right now we have this org.hibernate.transaction.TransactionManagerLookup contract which has morphed beyond a simple TM lookup. And wrt this discussion it is the point at which we make the decision to support only JTA-compliant TMs because org.hibernate.transaction.TransactionManagerLookup defines a getUserTransactionName() method which returns the JNDI namespace where the UserTransaction can be located. If this were instead changed to actually return the UserTransaction instance I think it is much cleaner in the long run. Conceptually, I think the argument to make the change here is much stronger since it aligns with the actual roles these things fulfill. Of course, because it is disruptive, such a change would need to wait until until at least 3.4. In the meantime, I'll go ahead and apply this patch (sans the tab cleanup and some javadoc changes). - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: > Steve, Chris, > > What do you think? does this look good? > > On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > > Hey guys, > > > > I finally was able to attack this today and created an issue: > > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 > > > > The patch was created based on an SVN checkout of trunk and attached > > to the issue. Comments about the change and exactly what I did are > > detailed as well. > > > > The best thing about the fix is that I realized I didn't need to add > > any parent abstract classes or even subclasses. I was even able to > > consolidate a common JNDI lookup that was spread out (perhaps > > unnecessarily) across two classes into one class in one method. > > > > The change was pretty clean and only touched two files, but still > > retains backward compatibility. > > > > Please let me know what you think! > > > > Thanks, > > > > Les > > > > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > >> Hi Steve! > >> > >> Great to hear from you again :) > >> > >>> Not sure why you find it so interesting considering that that JTA spec > >>> itself *requires* binding into JNDI :) This is true both in the older > >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe > >>> that org.hibernate.transaction.JTATransaction is the correct place to > >>> be adding support for not acquiring these resources from JNDI. > >> > >> My frustration lies in the JTA spec itself, requiring JNDI due to > >> remnants from the EJB 2.1 era. Which is why I consider my approach to > >> be a feature request as opposed to a bug - its a 'nice to have' when > >> using a JTA TM that doesn't require JNDI. > >> > >> And I agree that JTATransaction _should_ be using the JNDI lookup - my > >> intention was never to change that, ensuring 100% backwards > >> compatibility. My intention was that the JTATransaction was a minimal > >> subclass of a parent abstract class. That abstract class would > >> delegate to children classes how do do the lookup, and in the > >> JTATransaction case, it would do it from JNDI, just as things occur > >> today. > >> > >>> However, I have no issue with adding support for these psuedo-JTA TMs. > >>> Its just a matter of semantics and being consistent with terminology. > >>> So, the basic thing we are trying to describe is support for interacting > >>> with "distributed transaction" systems. So, I'd prefer that the base > >>> class in question here be called DistributedTransaction, of which > >>> JTATransaction would be a subclass with the same behavior as it has > >>> today (some delegated to its new super). And from there we can begin to > >>> build the support for Atomikos and the other TP services not conforming > >>> to the JNDI aspect of the JTA spec. > >> > >> Perfect, this is exactly my thinking as well. And I much prefer your > >> superclass name ;) I'll post to this list again when I have my patch > >> attached to the issue so you guys can see the end result. > >> > >> Thanks again, > >> > >> Les > >> > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
