Dan, Generally speaking you are correct. I agree that transaction APIs should be moved outside of persistence to allow other modules to use them without needing to use persistence. I have already opened (and mostly coded) SEAMPERSIST-35 which separates the SeamManaged annotation from persistence. The annotation was already moved to solder by Stuart in SOLDER-77. I hope that SEAMPERSIST-35 can be integrated with Final so that the API calls are clear up front. So I guess what else needs to come out and what does the timeframe look like for post Seam 3.0.0 for a supplemental release? I was targetting May for JCR. To echo George's point, I've seen a few forum posts about JTA dependencies in Seam Persistence, when running it in a tomcat environment. Is it possible for us to do this, while possibly degrading softly when it's not around?
John On Fri, Mar 11, 2011 at 8:39 PM, Dan Allen <[email protected]> wrote: > I'd also add that we are using transactions in the Faces module to provide > managed transactions integrated into the JSF lifecycle. So again, we see the > transaction support used as a top-level feature. > > -Dan > > > On Fri, Mar 11, 2011 at 20:33, Dan Allen <[email protected]> wrote: > >> On Fri, Mar 11, 2011 at 20:15, George Gastaldi <[email protected]>wrote: >> >>> Nice, I agree that it is the right way to go. I was almost suggesting >>> separating that on a separate module also. >>> >>> However it must be considered that JTA would not always be used (when >>> running on tomcat for example). How would this module handle these scenarios >>> ? Would it depend on persistence module itself ? >>> >> >> The Seam transaction API is an abstraction over JTA. It provides the same >> interface, but can accommodate a different providers underneath. >> >> For instance, you should be able to adapt it to any single resource >> transaction (recognizing that you lose multiple resource enlistment) >> (similar to what spring does: >> http://www.infoq.com/articles/spring-modules-jcr). The module could even >> go a step further and provide simplified transaction configuration for JTA >> in a standalone environment. I think there is a lot of interesting avenues >> to explore, which is why having it in a separate module makes a ton of >> sense. The floor is open for discussion. >> >> -Dan >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev > >
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
