On Wed, Apr 14, 2010 at 10:27 PM, Clint Popetz <cpopetz(a)gmail.com> wrote:
On Wed, Apr 14, 2010 at 9:08 PM, Dan Allen
<dan.j.allen(a)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