[hibernate-dev] Work on HHH-3110

[Les Hazlewood]

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
>