Hi Les,
I also had the same issue which was fixed using an update of the transaction manager I use (Bitronix 1.3). A light JNDI server is now embedded in it... For info, the main developer of Bitronix is also working for Atomikos (JTA world seems to be small ;-) My JNDI hibernate.cfg.xml is now defined as follow: <property name="hibernate.jndi.url"/> <property name="hibernate.jndi.class">bitronix.tm.jndi.BitronixInitialContextFactory</property> Regards, Joël On Thu, 2008-06-19 at 16:42 -0400, Les Hazlewood wrote: > 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 > _______________________________________________ > 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
