http://hibernate.org/436.html is the developer resource page. If you click through the "Intellij User Info" link it will show you the style config I use. Unfortunately our wiki does not have attachment capability, so the style xml doc is there inline; just follow the instructions...
It'll be in 3.3.0 and 3.2.7 - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, 2008-06-26 at 13:36 -0400, Les Hazlewood wrote: > On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@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
