Re: [hibernate-dev] Work on HHH-3110
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(a)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