[hibernate-dev] Work on HHH-3110

Hi guys, It has been a while since I've talked to most of the Hibernate team - I hope all is well with everyone. I can say that I miss that I miss working with the people, not so much the consulting travel :-P Anyway, lemme get to business. I upgraded from 3.2.5 to 3.2.6 and started getting exceptions about JNDI. The company I'm working with uses Atomikos standalone transaction manager outside of a JEE environment (no JNDI necessary), I found this issue that exactly describes what I'm seeing: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3110 It was interesting to see from many posts on the web that many other people are seeing the same issue, BTM, Jotm, Atomikos users, etc... So, I started thinking, and communicated with Chris since the issue was assigned to him. Here's a summary: Les: I want to make some architectural adjustments to the org.hibernate.transaction.JTATransaction implementation that would work with or without JNDI, but be fully backwards compatible. Any objections to me assigning the issue to myself? Chris: I have an objection only insomuch as JTA implies JNDI availability. Open up this issue on hibernate-dev and let's flesh it out with Steve. I think the right solution is to provide an additional implementation that uses JOTM directly, as suggested by Felix on the JIRA case. So, here I am. The issue with JTATransaction is that it acquires the the UserTransaction object via a JNDI lookup. If JNDI isn't being used, we have the exception. The proposed solution is to create an AbstractJTATransaction that does exactly what the current implementation does, but abstracts the UserTransaction lookup to subclasses. Then JTATransaction would subclass AbstractJTATransaction and implement the default JNDI lookup logic as exists today. A new class, say a StandaloneJTATransaction would subclass AbstractJTATransaction and acquire it via a different mechanism - probably the TM-specific TransactionManagerLookup implementation looks it up first and then passes it in the StandaloneJTATransaction constructor. Anyway, this would be fully backwards compatible because the JTATransaction implementation would retain the same API and functionality. It would just support non-JNDI environments very cleanly and the TransactionManagerLookup implementation, which is already TM-specific, would know what to do based on if it requires JNDI or not. So what do you think? Can I make this change in my local environment and upload the patch to the issue to see how you guys like it? It would make a lot of users (including me ;) ) quite happy, while still retaining the JNDI defaults as expected by JTA. Cheers! Les