I had a long email typed up, but in short:<br><br>Users can decide to use the transaction object as a UserTransaction, or they can use it as a SeamTransaction (or whatever it ends up being called) and get the extra features -- the name of this design pattern is eluding me, but I think it fits well here.<br>
<br>This alleviates the extra step of injecting the UserTransaction, then injecting the utility (or instantiating it) and passing the UserTransaction in to get the desired behavior.<br><br>Two+ steps reduced to one. I'm with Dan here.<br>
<br>--Lincoln<br><br><div class="gmail_quote">On Wed, Apr 14, 2010 at 3:00 PM, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>></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"><div class="gmail_quote">On Wed, Apr 14, 2010 at 2:25 PM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></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><br>
On 14 Apr 2010, at 19:21, Dan Allen wrote:<br>
<br>
> On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>> wrote:<br>
> I'm with Emmanuel here.<br>
><br>
> All of this is addressable through an Transactions utiltiy class.<br>
><br>
> Let me ask for two clarifications that will help me understand the counter argument.<br>
><br>
> 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.<br>
> 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?<br>
<br>
</div>What interface does the client reference in their code?<br>
<br>
I think you are confusing two concepts.</blockquote></div><br></div>By "client", I am referring to other modules (and in rarer cases the developer's application). A use case would probably help here.<div><br>
</div>
<div>The Faces module needs to provide the Seam-managed transactions that tie into the JSF lifecycle. (Let's call them "lifecycle transactions" rather than the term "global", which I have used in the past). That integration needs to get a handle on the transaction API. We don't want to tie ourselves to the native JTA UserTransaction or else we put environments without JTA out in the cold (e.g., servlet containers).</div>
<div><br></div><div>What I am proposing a producer method that grabs the transaction of choice (defaulting to JTA if it's available), wraps it inside of an object that implements JTA UserTransaction with some extra convenience methods (the status and enlist methods we previously discussed), and returns it. The Faces module can then use this extended UserTransaction to interact with whatever transaction API is being used under the covers.</div>
<div><br></div><div>This model worked well for us in Seam 2. I'm trying to understand why we are rescinding on our past decisions. </div><div><div></div><div class="h5"><div><br></div><div>-Dan<br clear="all"><br>-- <br>
Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>
Registered Linux User #231597<br><br><a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
<a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><br>
</div>
</div></div><br>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></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>"Keep it Simple"<br>