Ok, yeah +1, I&#39;m completely sold now.<br><br><div class="gmail_quote">On Wed, Apr 14, 2010 at 10:27 PM, Clint Popetz <span dir="ltr">&lt;<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, Apr 14, 2010 at 9:08 PM, Dan Allen &lt;<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Right. I&#39;m imagining that we can inject the native UserTransaction interface<br>
&gt; or our extended interface, but either way you are getting the same bean<br>
&gt; instance. Internally we stick the our extended interface to keep the code<br>
&gt; readable, the user gets a choice.<br>
&gt; It&#39;s not just about wrapping these few status methods and adding the enlist<br>
&gt; method. It&#39;s about taring the transaction API to a single interface.<br>
&gt; Basically, UserTransaction is the interface, the implementation could be<br>
&gt; non-JTA.<br>
<br>
<br>
</div>This is also important in mock environments.  We use JTA in J2EE<br>
containers, but not in unit test land (or in development container<br>
environments like Jetty), and Seam&#39;s transaction API allows us to<br>
easily stub out the same API in the latter case.<br>
<font color="#888888"><br>
-Clint<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>&quot;Keep it Simple&quot;<br>