I skimmed through the document. I think the transaction API is a bad idea. http://seamframework.org/Seam3/PersistenceModuleOverview#H-SimplifiedTran... It's a major issue that everyone and his dog reinvents a Tx API where JTA is almost perfect. I agree with the non-intuitiveness of using getStatus() (esp. pre Enums). But that's nothing a small helper class can fix. On 13 avr. 2010, at 19:06, Dan Allen wrote: I have put together an initial draft of the persistence module page [1]. I've outlined the major issues that this module needs to address along with some rough design notes. The next step is to identify what features to tackle first by sketching out a roadmap (alpha1, alpha2, etc with bullets next to them). I'll take the first stab at it. - If you are a current Seam committer interested in helping with this module, please add your name to the table and feel free to revise or add to the design notes. - If you are not a Seam committer, you can start by helping with the design notes and we can work you up to committer status as you demonstrate commitment and expertise. Like the security module, the persistence module is very important because it fills a gap that still exists in Java EE (transactions for non-EJB managed beans). Developers are mostly likely going to need this module to write an app, primarily if they are trying to avoid using EJBs. I still believe that we should advocate EJB 3.1, though, despite working on this module. We could consider it a half-way house for people who have been burned by EJB in the past :) -Dan [1 http://seamframework.org/Seam3/PersistenceModule -- 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 _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

I skimmed through the document. I think the transaction API is a bad idea. http://seamframework.org/Seam3/PersistenceModuleOverview#H-SimplifiedTran... It's a major issue that everyone and his dog reinvents a Tx API where JTA is almost perfect. I agree with the non-intuitiveness of using getStatus() (esp. pre Enums). But that's nothing a small helper class can fix. On 13 avr. 2010, at 19:06, Dan Allen wrote: > I have put together an initial draft of the persistence module page [1]. I've outlined the major issues that this module needs to address along with some rough design notes. The next step is to identify what features to tackle first by sketching out a roadmap (alpha1, alpha2, etc with bullets next to them). I'll take the first stab at it. > > - If you are a current Seam committer interested in helping with this module, please add your name to the table and feel free to revise or add to the design notes. > - If you are not a Seam committer, you can start by helping with the design notes and we can work you up to committer status as you demonstrate commitment and expertise. > > Like the security module, the persistence module is very important because it fills a gap that still exists in Java EE (transactions for non-EJB managed beans). Developers are mostly likely going to need this module to write an app, primarily if they are trying to avoid using EJBs. I still believe that we should advocate EJB 3.1, though, despite working on this module. We could consider it a half-way house for people who have been burned by EJB in the past :) > > -Dan > > [1 http://seamframework.org/Seam3/PersistenceModule > > -- > 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 _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <pmuir(a)redhat.com&gt; 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?

On Wed, Apr 14, 2010 at 2:25 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > On 14 Apr 2010, at 19:21, Dan Allen wrote: > > > On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <pmuir(a)redhat.com&gt; 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? > > What interface does the client reference in their code? > > I think you are confusing two concepts. By "client", I am referring to other modules (and in rarer cases the developer's application). A use case would probably help here. 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). 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. This model worked well for us in Seam 2. I'm trying to understand why we are rescinding on our past decisions. -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

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.

On Wed, Apr 14, 2010 at 9:08 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; 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

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&gt; 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?

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

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