[hibernate-dev] Work on HHH-3110

[joël Winteregg]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev