Right, and the question is, why not do the same thing again? Since that
seems to work well, and will be familiar to Seam 2 users
--Lincoln
On Thu, Apr 15, 2010 at 6:17 AM, Pete Muir <pmuir(a)redhat.com> wrote:
On 15 Apr 2010, at 08:15, Emmanuel Bernard wrote:
>
> On 14 avr. 2010, at 20:21, Dan Allen wrote:
>
>> On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <pmuir(a)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?
>
> So your proposal was only describing what already exists here?
>
http://docs.jboss.org/seam/2.2.1.CR1/api/org/jboss/seam/transaction/UserT...
>
> If yes then, that's fine. But frankly the wiki wording sounds like you
are on your way to design a brand new API.
>
> So if the proposal is:
> - create an extension of javax.transaction.UserTransaction to provide
convenience methods
> - use this interface as a wrapper around all the transaction apis out
there (ie basically using javax.transaction.UserTransaction as the tx
gateway for everyone - unit test up to JTA)
> - provide implementations of these wrappers
>
> then that's cool but isn't it already what Seam 2 does?
Yes.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev