[hibernate-dev] Work on HHH-3110

[Les Hazlewood]

Oh, please feel free to resolve/close
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358
when the patch is applied/tests run, etc...

On Thu, Jun 26, 2008 at 1:36 PM, Les Hazlewood <les at hazlewood.com> 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
>>
>>
>