Another option is for the transaction utility class to provide the
convenience methods without extending UserTransaction, i.e like this:
public boolean isActive(UserTransaction transaction) {
return transaction.getStatus() == STATUS.ACTIVE;
}
On 15/04/10 04:21, Dan Allen wrote:
On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <pmuir(a)redhat.com
<mailto:pmuir@redhat.com>> wrote:
I'm with Emmanuel here.
All of this is addressable through an Transactions utiltiy class.
Let me ask for two clarifications that will help me understand the
counter argument.
1. If this transaction wrapper extends UserTransaction, is that
worse/different than having a utility class? You can always inject the
native type, or inject the wrapper for the extra convenient status
methods.
2. The transaction wrapper allows us reuse the UserTransaction API to
address JTA, resource-local and potentially spring transaction APIs as
one. The client then doesn't concern itself with which transaction API
is being used under the covers, but everyone "speaks" JTA
UserTransaction. How do we do that with just a utility class?
-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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev