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

And I know that works, but I feel like it is a hack. If the underlying TM doesn't require JNDI, why force it just to get around a lookup that is meaningless? Also, this would make a lot of other people happy.

In other words, this problem wasn't in 3.2.5 and below, and with my proposed fix, it wouldn't be there in the future, and would be 100% backwards compatible. Sounds like a pretty sweet deal to me ;) On Thu, Jun 19, 2008 at 5:32 PM, joël Winteregg <joel.winteregg(a)gmail.com&gt; wrote: > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >