On Wed, Apr 14, 2010 at 10:27 PM, Clint Popetz <cpopetz@gmail.com> wrote:
On Wed, Apr 14, 2010 at 9:08 PM, Dan Allen <dan.j.allen@gmail.com> wrote:

> Right. I'm imagining that we can inject the native UserTransaction interface
> or our extended interface, but either way you are getting the same bean
> instance. Internally we stick the our extended interface to keep the code
> readable, the user gets a choice.
> It's not just about wrapping these few status methods and adding the enlist
> method. It's about taring the transaction API to a single interface.
> Basically, UserTransaction is the interface, the implementation could be
> non-JTA.


This is also important in mock environments.  We use JTA in J2EE
containers, but not in unit test land (or in development container
environments like Jetty), and Seam's transaction API allows us to
easily stub out the same API in the latter case.

Truth be told, it's possible to swap out the JTA impl with a mock in a test environment even without our enhancement. CDI provides a UserTransaction bean in a container environment for injection. All beans can be overridden. Overriding is as simple as providing an @Alternative bean.

That also means we could have an @Alternative for each type of transaction we are supporting, but I'm still interested in extending the built-in bean anyway to have an enhanced interface because there are some other elements to the abstraction than just changing the UserTransaction impl.

-Dan
 
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen