[hibernate-dev] Work on HHH-3110

[joël Winteregg]

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