[hibernate-dev] Work on HHH-3110

[Les Hazlewood]

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