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
