[hibernate-dev] Work on HHH-3110
Steve Ebersole
steve at hibernate.org
Thu Jun 26 13:58:36 EDT 2008
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
steve at hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebersole at jboss.com
steve.ebersole at redhat.com
On Thu, 2008-06-26 at 13:36 -0400, Les Hazlewood wrote:
> On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <steve at hibernate.org> 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 at hazlewood.com> 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 at hazlewood.com> 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
More information about the hibernate-dev
mailing list