Re: [hibernate-dev] Work on HHH-3110

On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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. Ah, yes, I'll definitely do that - my apologies. I'm assuming there is a style guide that I can use to ensure IntelliJ is set up appropriately? > > 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). Very cool - thanks so much. In which release will it be available (so I can tell the Atomikos guys)? Cheers, Les > 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 <les(a)hazlewood.com&gt; 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 <les(a)hazlewood.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >