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: > How is the UserTransaction you're mentioning different than the one Spring provides? > http://static.springsource.org/spring/docs/3.0.x/spring-framework-referen... > 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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

> 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. > Correct. I've also tried Atomikos Essentials, which I actually did get to work, but should everyone have to fill out a form to use transactions? http://www.atomikos.com/Main/TransactionsEssentialsDownloadForm That strengthens Gavin's point about how screwed up this situation with transactions has become. What we we need a simple, reliable, documented way for developers to educate Tomcat how to do transactions correctly. I'm praying that EJB lite is that solution. I've heard some promising statements and we want to confirm them through our archetypes. The whole idea of creating these archetypes, as Steven said, is to get the developer using CDI, JSF 2, JPA and JTA without even a moment of time wasted, with their choice of Tomcat, Jetty or a Java EE container. When we have that, we will have accomplished our first, and most critical, goal. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

That's more or less an easy problem to solve. But why do you want to inject it using @PersistenceContext instead of @Inject??

wrote:

So normally on JEE6, you'd user @PersistenceContext, right? That's certainly the case if you're using JEE5 or Spring right now. Therefore if switching containers or running in SE, they'd have to change all @PersitenceContext annotations to @Inject, correct? If you're asking me, representing myself, I don't care much. I don't get too worked up if I have to jump through a hoop or two to get the plumbing in my app configured. I just want effective documentation to know how to get my job done. At the end of the day, my users care about my application's features, reliability, and response time. I know how to work my IDE's find and replace if I find myself in that situation. As an experienced user, I am used to working around "paper cuts." Trying to put myself in the user's place, it'd be nice if their Java code could be switched between containers. I think the platform looks better if there is minimal branching, especially on the Java side. If we're reaching out to SE and Servlet users, it'd be ideal if they could use the same annotations. However, I don't think this one tiny detail alone will be a big enough reason to lose a user. As long as things are well documented, experienced professionals will just follow the directions to get the plumbing out of the way and move on to doing the interesting part of their application. IMO the biggest concern will be when writing examples. I think the less motivated and experienced users will get frustrated when they paste a sample from an example app, blog post, or documentation and get a null pointer exception. Will JEE6 users get a NPE if they use @Inject EntityManager em; without special configuration? Why is it so much more difficult to inject via @PersistenceContext than @Inject? Gavin King wrote: > That's more or less an easy problem to solve. But why do you want to > inject it using @PersistenceContext instead of @Inject?? > >

No, in EE5 you used @PersistenceContext, which is nontypesafe and doesn't support stuff like alternatives. In EE6 you should use CDI to @Inject your EntityManager just like any other bean.

That's more or less an easy problem to solve. But why do you want to inject it using @PersistenceContext instead of @Inject?? On Sat, Nov 28, 2009 at 11:47 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > There's also the issue of injecting an EntityManager (@PersistenceContext) > in Tomcat/Jetty, which, to my knowledge, there is no solution (apart from > EJB lite). Yes, the servlet containers are deficient, so what we are > essentially doing is migrating users to the Web Profile from Tomcat/Jetty. > > -Dan > > On Sat, Nov 28, 2009 at 11:42 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: >> >>> >>> 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. >> >> Correct. I've also tried Atomikos Essentials, which I actually did get to >> work, but should everyone have to fill out a form to use transactions? >> http://www.atomikos.com/Main/TransactionsEssentialsDownloadForm That >> strengthens Gavin's point about how screwed up this situation with >> transactions has become. >> >> What we we need a simple, reliable, documented way for developers to >> educate Tomcat how to do transactions correctly. I'm praying that EJB lite >> is that solution. I've heard some promising statements and we want to >> confirm them through our archetypes. The whole idea of creating these >> archetypes, as Steven said, is to get the developer using CDI, JSF 2, JPA >> and JTA without even a moment of time wasted, with their choice of Tomcat, >> Jetty or a Java EE container. When we have that, we will have accomplished >> our first, and most critical, goal. >> >> -Dan >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> http://www.google.com/profiles/dan.j.allen > > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://www.google.com/profiles/dan.j.allen > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Look, JOTM has always been a p.o.s, frankly. Atomikos is supposedly better. But why did you not try JBoss transactions?! Arjuna was always a *much* more sold product!