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

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...

I agree with you Chris, it does better simulate it. But Hibernate has always been deployable outside of a container. Shouldn't it retain that philosophy in its code base as well, architecting flexible approaches that work seamlessly both in a JEE container and out? That's my belief... On Thu, Jun 19, 2008 at 5:39 PM, Chris Bredesen <cbredesen(a)redhat.com&gt; wrote: > joël Winteregg wrote: >> >> 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... > > This is an alternative that I've discussed with others off list. IMHO, this > better simulates the in-container JTA environment. > > -Chris > >

Les Hazlewood wrote: > > I agree with you Chris, it does better simulate it. But Hibernate has > always been deployable outside of a container. Shouldn't it retain > that philosophy in its code base as well, architecting flexible > approaches that work seamlessly both in a JEE container and out? > > That's my belief... Sure, and that's exactly why all this stuff is pluggable. An alternative would be for the TM projects to incorporate implementations of the Hibernate classes that most efficiently use their own APIs. MySQL, for example, provides a JBoss ValidConnectionChecker that is statically linked to their own driver. Collaboration like this is great, IMHO. Does your proposed implementation require Atomikos to be on the classpath in order to build Hibernate? The use of JNDI decouples Hibernate from the TM in a well-specified way. -Chris

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 Whatever you wind up doing, I think it would be best to open a new feature request JIRA, link to HHH-3110 and attach your patch to it... -Chris

Not sure why you find it so interesting considering that that JTA spec itself *requires* binding into JNDI :) This is true both in the older 1.0.1B as well as the latest 1.1 specs. Thus I do not believe that org.hibernate.transaction.JTATransaction is the correct place to be adding support for not acquiring these resources from JNDI.

However, I have no issue with adding support for these psuedo-JTA TMs. Its just a matter of semantics and being consistent with terminology. So, the basic thing we are trying to describe is support for interacting with "distributed transaction" systems. So, I'd prefer that the base class in question here be called DistributedTransaction, of which JTATransaction would be a subclass with the same behavior as it has today (some delegated to its new super). And from there we can begin to build the support for Atomikos and the other TP services not conforming to the JNDI aspect of the JTA spec.

Hey guys, I finally was able to attack this today and created an issue: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 The patch was created based on an SVN checkout of trunk and attached to the issue. Comments about the change and exactly what I did are detailed as well. The best thing about the fix is that I realized I didn't need to add any parent abstract classes or even subclasses. I was even able to consolidate a common JNDI lookup that was spread out (perhaps unnecessarily) across two classes into one class in one method. The change was pretty clean and only touched two files, but still retains backward compatibility. Please let me know what you think! Thanks, Les On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <les(a)hazlewood.com&gt; wrote: > Hi Steve! > > Great to hear from you again :) > >> Not sure why you find it so interesting considering that that JTA spec >> itself *requires* binding into JNDI :) This is true both in the older >> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe >> that org.hibernate.transaction.JTATransaction is the correct place to >> be adding support for not acquiring these resources from JNDI. > > My frustration lies in the JTA spec itself, requiring JNDI due to > remnants from the EJB 2.1 era. Which is why I consider my approach to > be a feature request as opposed to a bug - its a 'nice to have' when > using a JTA TM that doesn't require JNDI. > > And I agree that JTATransaction _should_ be using the JNDI lookup - my > intention was never to change that, ensuring 100% backwards > compatibility. My intention was that the JTATransaction was a minimal > subclass of a parent abstract class. That abstract class would > delegate to children classes how do do the lookup, and in the > JTATransaction case, it would do it from JNDI, just as things occur > today. > >> However, I have no issue with adding support for these psuedo-JTA TMs. >> Its just a matter of semantics and being consistent with terminology. >> So, the basic thing we are trying to describe is support for interacting >> with "distributed transaction" systems. So, I'd prefer that the base >> class in question here be called DistributedTransaction, of which >> JTATransaction would be a subclass with the same behavior as it has >> today (some delegated to its new super). And from there we can begin to >> build the support for Atomikos and the other TP services not conforming >> to the JNDI aspect of the JTA spec. > > Perfect, this is exactly my thinking as well. And I much prefer your > superclass name ;) I'll post to this list again when I have my patch > attached to the issue so you guys can see the end result. > > Thanks again, > > Les >

One thing I'd ask for future is that you stick to hibernate style as it makes it easier to see *real* changes. For example, you are using space-expansion in place of tabs, etc.

This discussion has come up before and I had been thinking of another approach to address this, however, my approach is more disruptive. Basically, right now we have this org.hibernate.transaction.TransactionManagerLookup contract which has morphed beyond a simple TM lookup. And wrt this discussion it is the point at which we make the decision to support only JTA-compliant TMs because org.hibernate.transaction.TransactionManagerLookup defines a getUserTransactionName() method which returns the JNDI namespace where the UserTransaction can be located. If this were instead changed to actually return the UserTransaction instance I think it is much cleaner in the long run. Conceptually, I think the argument to make the change here is much stronger since it aligns with the actual roles these things fulfill. Of course, because it is disruptive, such a change would need to wait until until at least 3.4. In the meantime, I'll go ahead and apply this patch (sans the tab cleanup and some javadoc changes).

On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: > Steve, Chris, > > What do you think? does this look good? > > On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <les(a)hazlewood.com&gt; wrote: > > Hey guys, > > > > I finally was able to attack this today and created an issue: > > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 > > > > The patch was created based on an SVN checkout of trunk and attached > > to the issue. Comments about the change and exactly what I did are > > detailed as well. > > > > The best thing about the fix is that I realized I didn't need to add > > any parent abstract classes or even subclasses. I was even able to > > consolidate a common JNDI lookup that was spread out (perhaps > > unnecessarily) across two classes into one class in one method. > > > > The change was pretty clean and only touched two files, but still > > retains backward compatibility. > > > > Please let me know what you think! > > > > Thanks, > > > > Les > > > > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <les(a)hazlewood.com&gt; wrote: > >> Hi Steve! > >> > >> Great to hear from you again :) > >> > >>> Not sure why you find it so interesting considering that that JTA spec > >>> itself *requires* binding into JNDI :) This is true both in the older > >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe > >>> that org.hibernate.transaction.JTATransaction is the correct place to > >>> be adding support for not acquiring these resources from JNDI. > >> > >> My frustration lies in the JTA spec itself, requiring JNDI due to > >> remnants from the EJB 2.1 era. Which is why I consider my approach to > >> be a feature request as opposed to a bug - its a 'nice to have' when > >> using a JTA TM that doesn't require JNDI. > >> > >> And I agree that JTATransaction _should_ be using the JNDI lookup - my > >> intention was never to change that, ensuring 100% backwards > >> compatibility. My intention was that the JTATransaction was a minimal > >> subclass of a parent abstract class. That abstract class would > >> delegate to children classes how do do the lookup, and in the > >> JTATransaction case, it would do it from JNDI, just as things occur > >> today. > >> > >>> However, I have no issue with adding support for these psuedo-JTA TMs. > >>> Its just a matter of semantics and being consistent with terminology. > >>> So, the basic thing we are trying to describe is support for interacting > >>> with "distributed transaction" systems. So, I'd prefer that the base > >>> class in question here be called DistributedTransaction, of which > >>> JTATransaction would be a subclass with the same behavior as it has > >>> today (some delegated to its new super). And from there we can begin to > >>> build the support for Atomikos and the other TP services not conforming > >>> to the JNDI aspect of the JTA spec. > >> > >> Perfect, this is exactly my thinking as well. And I much prefer your > >> superclass name ;) I'll post to this list again when I have my patch > >> attached to the issue so you guys can see the end result. > >> > >> Thanks again, > >> > >> Les > >> > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > One thing I'd ask for future is that you stick to hibernate style as it > makes it easier to see *real* changes. For example, you are using > space-expansion in place of tabs, etc. Ah, yes, I'll definitely do that - my apologies. I'm assuming there is a style guide that I can use to ensure IntelliJ is set up appropriately? > > This discussion has come up before and I had been thinking of another > approach to address this, however, my approach is more disruptive. > Basically, right now we have this > org.hibernate.transaction.TransactionManagerLookup contract which has > morphed beyond a simple TM lookup. And wrt this discussion it is the > point at which we make the decision to support only JTA-compliant TMs > because org.hibernate.transaction.TransactionManagerLookup defines a > getUserTransactionName() method which returns the JNDI namespace where > the UserTransaction can be located. If this were instead changed to > actually return the UserTransaction instance I think it is much cleaner > in the long run. Conceptually, I think the argument to make the change > here is much stronger since it aligns with the actual roles these things > fulfill. Of course, because it is disruptive, such a change would need > to wait until until at least 3.4. > > In the meantime, I'll go ahead and apply this patch (sans the tab > cleanup and some javadoc changes). Very cool - thanks so much. In which release will it be available (so I can tell the Atomikos guys)? Cheers, Les > On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: >> Steve, Chris, >> >> What do you think? does this look good? >> >> On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <les(a)hazlewood.com&gt; wrote: >> > Hey guys, >> > >> > I finally was able to attack this today and created an issue: >> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 >> > >> > The patch was created based on an SVN checkout of trunk and attached >> > to the issue. Comments about the change and exactly what I did are >> > detailed as well. >> > >> > The best thing about the fix is that I realized I didn't need to add >> > any parent abstract classes or even subclasses. I was even able to >> > consolidate a common JNDI lookup that was spread out (perhaps >> > unnecessarily) across two classes into one class in one method. >> > >> > The change was pretty clean and only touched two files, but still >> > retains backward compatibility. >> > >> > Please let me know what you think! >> > >> > Thanks, >> > >> > Les >> > >> > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <les(a)hazlewood.com&gt; wrote: >> >> Hi Steve! >> >> >> >> Great to hear from you again :) >> >> >> >>> Not sure why you find it so interesting considering that that JTA spec >> >>> itself *requires* binding into JNDI :) This is true both in the older >> >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe >> >>> that org.hibernate.transaction.JTATransaction is the correct place to >> >>> be adding support for not acquiring these resources from JNDI. >> >> >> >> My frustration lies in the JTA spec itself, requiring JNDI due to >> >> remnants from the EJB 2.1 era. Which is why I consider my approach to >> >> be a feature request as opposed to a bug - its a 'nice to have' when >> >> using a JTA TM that doesn't require JNDI. >> >> >> >> And I agree that JTATransaction _should_ be using the JNDI lookup - my >> >> intention was never to change that, ensuring 100% backwards >> >> compatibility. My intention was that the JTATransaction was a minimal >> >> subclass of a parent abstract class. That abstract class would >> >> delegate to children classes how do do the lookup, and in the >> >> JTATransaction case, it would do it from JNDI, just as things occur >> >> today. >> >> >> >>> However, I have no issue with adding support for these psuedo-JTA TMs. >> >>> Its just a matter of semantics and being consistent with terminology. >> >>> So, the basic thing we are trying to describe is support for interacting >> >>> with "distributed transaction" systems. So, I'd prefer that the base >> >>> class in question here be called DistributedTransaction, of which >> >>> JTATransaction would be a subclass with the same behavior as it has >> >>> today (some delegated to its new super). And from there we can begin to >> >>> build the support for Atomikos and the other TP services not conforming >> >>> to the JNDI aspect of the JTA spec. >> >> >> >> Perfect, this is exactly my thinking as well. And I much prefer your >> >> superclass name ;) I'll post to this list again when I have my patch >> >> attached to the issue so you guys can see the end result. >> >> >> >> Thanks again, >> >> >> >> Les >> >> >> > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >