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

[Gavin King]

Steven, you're not at all annoying, and I appreciate the time and care
you're putting into this. My anti-Spring rants are supposed to make
you smile, and perhaps question some assumptions. I enjoy being
contrarian. Don't take it the wrong way. Everyone is welcome here. We
do *not* value groupthink here, and we don't try to ostracize folks we
disagree with.

My rant about transaction management was a (lighthearted) expression
of my dismay at the fact that the Java community is now so utterly
fragmented that we are apparently unable to agree on the name of an
interface with 3 methods, and totally well-understood semantics. This
"issue" that we are dealing with in this thread is a 100% political,
invented problem. The actual real problems involved in tx management
were solved a decade ago. It reflects badly upon the Java community
that we all invent our own flavor of UserTransaction. And I include
myself in this criticism, since I was present at the birth of two of
those favors (org.hibernate.Transaction and
javax.persistence.EntityTransaction) and missed the opportunity to
fight against both those abominations (even though I was skeptical of
both at the time). I could perhaps forgive myself
org.hibernate.Transaction since I was young and stupid, but by the
time EntityTransaction rolled round I should have, and did, know
better.

On Tue, Nov 24, 2009 at 10:08 PM, Boscarine, Steven
<Steven.Boscarine at childrens.harvard.edu> wrote:
> 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



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org