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

[Reza Rahman]

Steven,

Personally, I am happy to answer whatever questions you have vis-a-vis 
CDI and Spring. I've used Spring for a few years now and do value it for 
some things but not others.

As to what Dan is referring to, it is likely JOTM: 
http://jotm.objectweb.org, which you won't have to deal with whether you 
are using an embedded EJB Lite container or a CDI specific transaction 
manager with JPA on Tomcat.

Hope it helps,
Reza

P.S.: You might find this presentation I did at JBossWorld useful: 
http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. I also 
just started a series of articles on TSS covering CDI: 
http://www.theserverside.com/tt/articles/article.tss?l=DependencyInjectioninJavaEE6.


Boscarine, Steven 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
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>