Hi again, > 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. >
I agree with you... For me at least (I'm not a J2EE infrastructure expert) that would have been much easier to use a standalone transaction manager without using JNDI dependencies... That's why an embedded JNDI into the transaction manager was a nice (easy) solution ;-) Regards, Joël > 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 > <[EMAIL PROTECTED]> 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@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