Oh, please feel free to resolve/close http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 when the patch is applied/tests run, etc...
On Thu, Jun 26, 2008 at 1:36 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <[EMAIL PROTECTED]> 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 <[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
