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

[Boscarine, Steven]

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 at 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 at childrens.harvard.edu> wrote:
> How is the UserTransaction you're mentioning different than the one Spring provides?
> http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/ch10.html

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 at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org