[weld-dev] rationale for JTA/JPA questions - trying to add JPA support to archetypes

I honestly can't tell your tone in your responses as to whether or not you're getting annoyed with these questions on this list and the forums. I am not trying to troll on Spring's behalf and am sincerly trying to help get JSF 2 and CDI adopted in my organization, local user groups, and promote it to those who are willing to read what I'm writing both on your site and what I am trying to write about on our blog. That's why I am working with Dan and Pete on the archetypes. The whole motivation for the asking about JPA in the first place is because I wanted to put JPA support in the Weld archetypes and documentation. http://seamframework.org/Documentation/WeldQuickstartForMavenUsers If tomcat users need to use EJBLite, I'm happy to put that in the documentation. I am just asking because I wasn't aware of what Dan was referring to when he said "Yes, if I spend half the day searching the web to find a tutorial that actually works, maybe I can "upgrade" these containers to support JTA, but that's a PITA." It was a sincere question because my experience was much different. I fully understand that Tomcat is limited compared to a JEE6. However, if there are reasonable hoops the Tomcat users can jump through to get basic functionality, such as JPA or basic transactions, I think it will be very beneficial to document them for the sake of CDI adoption. I am even happy to personally document polite arguments as to why it is to their benefit to switch to a "real container." I think it is quite reasonable to expect users to want to try out a new technology, such as JEE6 features like CDI, on their existing infrastructure and persuade their stakeholders to schedule an upgrade to a proper JEE6 container once their prototypes are successful and JBoss 6.0 is out of beta and has passed their internal tests. ________________________________________ From: Gavin King [gavin.king(a)gmail.com] Sent: Tuesday, November 24, 2009 7:45 PM To: Boscarine, Steven Cc: Dan Allen; Gurkan Erdogdu; Weld-Dev Subject: Re: [weld-dev] persistence and transactions outside Java EE On Tue, Nov 24, 2009 at 6:35 PM, Boscarine, Steven <Steven.Boscarine(a)childrens.harvard.edu&gt; wrote: Well, here's the difference. The JTA UserTransaction is defined by the JTA specification, and is supported by all real Java transaction managers. It's an abstraction that can accommodate just about any kind of transactional resource you can think of. It works perfectly with JDBC, JCA, JPA, Hibernate, JDO, etc. The Spring transaction manager is a totally proprietary API that ties your application to Spring, and provides an abstraction of ... other abstractions. It's a totally bogus, superfluous layer that provides no additional resource independence, nor additional high-level semantics, than what is already provided by JTA. If I wanted to continue making the world a better place by following in the footsteps of Spring, I would create a new transaction abstraction called WeldTransaction, which abstracts your application away from the underlying Spring or JTA transaction. Of course, then you would probably want to write your own transaction manager to abstract away from your choice of WeldTransaction, Spring or JTA for transaction management. This is pretty easy to do, since all these interfaces have the same three methods: begin(), commit() and rollback(). If you do this, you might want to consider contributing your work back to the Spring framework, so that all Spring users can benefit from your abstraction of our abstraction of their abstraction of JTA. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org