I chatted to Jonathan about this, he tells me the binary for JBossTS JTA is under 1MB with no external dependencies other than the JTA API (but we would probably need standalone JCA too). On 18 Nov 2009, at 23:10, Gavin King wrote: > I think we should try and follow the Java EE models as closely as > possible for this stuff. We should simply try and make the Java EE > code work outside EE 6. > > e.g. > > (1) use a resource declaration with @PersistenceContext(unitName=....) > to define a managed persistence context > (2) use JBoss Transactions to manage transactions in a servlet engine > - so instead of having a special tx manager for JDBC, it is just JTA > > Or is the 10meg download for JBoss Transactions just no good? > > -- > 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

None of the pools is XA aware - they will pool standard connections, but not XA ones that need XAResource enlistment to the JTA tx. The TransactionalDriver in JBossTS will do that, but it's pretty primitive compared to a real JCA. Jonathan. On 11/23/2009 05:16 PM, Gavin King wrote: > > Ah. Standalone JCA is a problem. But do we really need JCA, or can we > just let Hibernate use one of the standalone connection pools that it > ships with? > > On Mon, Nov 23, 2009 at 7:13 AM, Pete Muir<pmuir(a)redhat.com>  wrote: >> >> I chatted to Jonathan about this, he tells me the binary for JBossTS JTA >> is under 1MB with no external dependencies other than the JTA API (but we >> would probably need standalone JCA too). >> >> On 18 Nov 2009, at 23:10, Gavin King wrote: >> >>> I think we should try and follow the Java EE models as closely as >>> possible for this stuff. We should simply try and make the Java EE >>> code work outside EE 6. >>> >>> e.g. >>> >>> (1) use a resource declaration with @PersistenceContext(unitName=....) >>> to define a managed persistence context >>> (2) use JBoss Transactions to manage transactions in a servlet engine >>> - so instead of having a special tx manager for JDBC, it is just JTA >>> >>> Or is the 10meg download for JBoss Transactions just no good? >>> >>> -- >>> 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 >> >> > > > -- ------------------------------------------------------------ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903  Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)

On Monday 23 November 2009 12:34:59 Gavin King wrote: > Now, if you know of a good, reasonably easy to use standalone JCA > layer, I'm all ears, but AFAIK, there's nothing really available in > this space. There will be a JCA 1.6 standalone implementation, based on chapter 3.5 of the specification, available at some point. JIRA:  https://jira.jboss.org/jira/browse/JBJCA Best regards,  Jesper

You are correct that for various reasons, many developers are fixated on Tomcat and Jetty. However, I do believe that if there are embeddable Java EE alternatives, such as Embedded JBoss AS, then the grip on servlet containers will loosen. What these developers want is to be able to deploy their app over top of Maven (or whatever build tool offers this feature). They like the automatic download of the server and the "in place" style deployment. I'm sure there are some other features I'm overlooking, but in the end, it comes down to zero configuration and overall simplicity. Having to boot up and application server as a service is just not as appealing. But that isn't out of the reach of Java EE. -Dan On Mon, Nov 23, 2009 at 12:34 PM, Gavin King <gavin.king(a)gmail.com <mailto:gavin.king@gmail.com>> wrote: Yes, I understand the need for XA enlistment, but JBoss Transactions is already able to do that, right? What I'm saying is that you would use the TransactionalDriver together with a pool. Or does TransactionalDriver already do pooling? Yes, I understand that this is primitive compared to JCA. But we're dealing with the users who claim they don't want or need an application server. They, for their own, mostly incomprehensible, reasons, *want* to use Tomcat or Jetty or something without a JCA layer, together with one of the very inferior pooling solutions that are available in that environment. And they've been told for years by the Spring crowd that it's a good idea and that they should keep doing it. Now, you and I both know this to be a total load of bunk, but we have tried to argue with these people and it is futile. They read it in books, so it must be true. We all know that a couple of years of exposure to Spring turns good developers into drooling, brain-damaged automatons who believe anything you tell them as long as you wave around enough underspecified jargon like "lightweight" and remind them how much EJB sucked 5 years ago. Now, if you know of a good, reasonably easy to use standalone JCA layer, I'm all ears, but AFAIK, there's nothing really available in this space. On Mon, Nov 23, 2009 at 12:19 PM, Jonathan Halliday <jonathan.halliday(a)redhat.com <mailto:jonathan.halliday@redhat.com>> wrote: > > None of the pools is XA aware - they will pool standard connections, but not > XA ones that need XAResource enlistment to the JTA tx. The > TransactionalDriver in JBossTS will do that, but it's pretty primitive > compared to a real JCA. > > Jonathan. > > On 11/23/2009 05:16 PM, Gavin King wrote: >> >> Ah. Standalone JCA is a problem. But do we really need JCA, or can we >> just let Hibernate use one of the standalone connection pools that it >> ships with? >> >> On Mon, Nov 23, 2009 at 7:13 AM, Pete Muir&lt;pmuir(a)redhat.com <mailto:pmuir@redhat.com>> wrote: >>> >>> I chatted to Jonathan about this, he tells me the binary for JBossTS JTA >>> is under 1MB with no external dependencies other than the JTA API (but we >>> would probably need standalone JCA too). >>> >>> On 18 Nov 2009, at 23:10, Gavin King wrote: >>> >>>> I think we should try and follow the Java EE models as closely as >>>> possible for this stuff. We should simply try and make the Java EE >>>> code work outside EE 6. >>>> >>>> e.g. >>>> >>>> (1) use a resource declaration with @PersistenceContext(unitName=....) >>>> to define a managed persistence context >>>> (2) use JBoss Transactions to manage transactions in a servlet engine >>>> - so instead of having a special tx manager for JDBC, it is just JTA >>>> >>>> Or is the 10meg download for JBoss Transactions just no good? >>>> >>>> -- >>>> Gavin King >>>> gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> >>>> http://in.relation.to/Bloggers/Gavin >>>> http://hibernate.org >>>> http://seamframework.org >>>> _______________________________________________ >>>> weld-dev mailing list >>>> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>> >>> >> >> >> > > > -- > ------------------------------------------------------------ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, > Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons > (USA) and Brendan Lane (Ireland) > -- Gavin King gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/weld-dev -- 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

Dan Allen wrote: > You are correct that for various reasons, many developers are fixated on > Tomcat and Jetty. However, I do believe that if there are embeddable Java EE > alternatives, such as Embedded JBoss AS, then the grip on servlet containers > will loosen. > I agree with Dan very strongly. The sooner there's a JEE6 container that can be launched from maven, like Jetty or Tomcat can now, the "stickier" JEE6 will become and adoption rates will increase. The more steps in an evaluation that cannot be scripted the greater chance that the user will either make a mistake or find something else to do, like get back to work. :) IMO, a key group of developers you'd want to target are very busy people. For many of them, when they are evaluating new software, it is often at the expense of tasks that their management thinks is of higher priority. When they are checking out Weld or JSF2, they're often not doing what their manager wants them to do. If we make evaluating a technology easy and pleasant, I think they'll be more likely to want to go further and adopt the technology, tell their friends, train coworkers, contribute, schedule training, buy books, buy support contracts, hire consultants, etc. In my experience, busy developers are often employed by successful companies who have reasonable budgets. If the getting started procedure is frustrating, I think they're more likely to stop playing with new technology and just continue using their current technology (like struts or even pure JSP + Servlets), get back to work, etc. Currently, GlassFish v3 can be launched from Maven, but it was a side project by Koshuke Kawaguchi http://weblogs.java.net/blog/2008/04/28/glassfish-v3-just-got-embeddable It is not as well documented as Jetty and doesn't auto-deploy modified classes. It even shares the same plugin name (but different package) as the official Glassfish plugin which controls a locally installed plugin, making the plugin very confusing. I heard a rumor JBoss is working on an embeddable version of JBossAS which will have a maven plugin which will download and run a container like the Tomcat plugin. The instant it resembles a working product, I'll happily include it in the archetypes as I think it'll go a long way towards increasing JEE6 adoption. It'll make writing applications much easier for the user and make documenting how to get started a breeze for contributers like me. Thanks, Steven PS-If anyone hasn't yet used the Tomcat/Jetty/Glassfish plugins, I have an old blog post explaining how to use them here: http://info.rmatics.org/2009/04/02/increasing-your-productivity-by-using-...

Great points Steven. Btw, just to add to this discussion, Andrew Rubinger (who we just call ALR) just informed me of progress on running embedded JBoss from Maven. I haven't tried it yet because I am currently preparing for JSF Summit, but perhaps you'll have a chance to stomp on it after getting some turkey, Steven. Or anyone else. http://www.jboss.org/community/wiki/JBossEmbeddedASAutomationviaMaven It would be great to provide ALR with feedback early so that we can get this right. -Dan On Wed, Nov 25, 2009 at 10:54 PM, Steven Boscarine <steven.boscarine(a)childrens.harvard.edu <mailto:steven.boscarine@childrens.harvard.edu>> wrote: Dan Allen wrote: You are correct that for various reasons, many developers are fixated on Tomcat and Jetty. However, I do believe that if there are embeddable Java EE alternatives, such as Embedded JBoss AS, then the grip on servlet containers will loosen. I agree with Dan very strongly. The sooner there's a JEE6 container that can be launched from maven, like Jetty or Tomcat can now, the "stickier" JEE6 will become and adoption rates will increase. The more steps in an evaluation that cannot be scripted the greater chance that the user will either make a mistake or find something else to do, like get back to work. :) IMO, a key group of developers you'd want to target are very busy people. For many of them, when they are evaluating new software, it is often at the expense of tasks that their management thinks is of higher priority. When they are checking out Weld or JSF2, they're often not doing what their manager wants them to do. If we make evaluating a technology easy and pleasant, I think they'll be more likely to want to go further and adopt the technology, tell their friends, train coworkers, contribute, schedule training, buy books, buy support contracts, hire consultants, etc. In my experience, busy developers are often employed by successful companies who have reasonable budgets. If the getting started procedure is frustrating, I think they're more likely to stop playing with new technology and just continue using their current technology (like struts or even pure JSP + Servlets), get back to work, etc. Currently, GlassFish v3 can be launched from Maven, but it was a side project by Koshuke Kawaguchi http://weblogs.java.net/blog/2008/04/28/glassfish-v3-just-got-embeddable It is not as well documented as Jetty and doesn't auto-deploy modified classes. It even shares the same plugin name (but different package) as the official Glassfish plugin which controls a locally installed plugin, making the plugin very confusing. I heard a rumor JBoss is working on an embeddable version of JBossAS which will have a maven plugin which will download and run a container like the Tomcat plugin. The instant it resembles a working product, I'll happily include it in the archetypes as I think it'll go a long way towards increasing JEE6 adoption. It'll make writing applications much easier for the user and make documenting how to get started a breeze for contributers like me. Thanks, Steven PS-If anyone hasn't yet used the Tomcat/Jetty/Glassfish plugins, I have an old blog post explaining how to use them here: http://info.rmatics.org/2009/04/02/increasing-your-productivity-by-using-... -- 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

Add the right Andrew :-) On 26 Nov 2009, at 04:44, Steven Boscarine wrote: > Hello Andrew > I looked at the page, but haven't yet stepped through the source code. > > Is there a means of launching the plugin outside of an integration test? > > Does this use JBoss6? > > I am trying to get a JEE equivalent of Jetty's behavior when you launch > 'mvn jetty:run' > > Thanks, > Steven > > Dan Allen wrote: >> Great points Steven. >> >> Btw, just to add to this discussion, Andrew Rubinger (who we just call >> ALR) just informed me of progress on running embedded JBoss from >> Maven. I haven't tried it yet because I am currently preparing for JSF >> Summit, but perhaps you'll have a chance to stomp on it after getting >> some turkey, Steven. Or anyone else. >> >> http://www.jboss.org/community/wiki/JBossEmbeddedASAutomationviaMaven >> >> It would be great to provide ALR with feedback early so that we can >> get this right. >> >> -Dan >> >> >> >> On Wed, Nov 25, 2009 at 10:54 PM, Steven Boscarine >> <steven.boscarine(a)childrens.harvard.edu >> <mailto:steven.boscarine@childrens.harvard.edu>> wrote: >> >> Dan Allen wrote: >> >> You are correct that for various reasons, many developers are >> fixated on Tomcat and Jetty. However, I do believe that if >> there are embeddable Java EE alternatives, such as Embedded >> JBoss AS, then the grip on servlet containers will loosen. >> >> I agree with Dan very strongly. The sooner there's a JEE6 >> container that can be launched from maven, like Jetty or Tomcat >> can now, the "stickier" JEE6 will become and adoption rates will >> increase. >> The more steps in an evaluation that cannot be scripted the >> greater chance that the user will either make a mistake or find >> something else to do, like get back to work. :) >> >> IMO, a key group of developers you'd want to target are very busy >> people. For many of them, when they are evaluating new software, >> it is often at the expense of tasks that their management thinks >> is of higher priority. When they are checking out Weld or JSF2, >> they're often not doing what their manager wants them to do. >> If we make evaluating a technology easy and pleasant, I think >> they'll be more likely to want to go further and adopt the >> technology, tell their friends, train coworkers, contribute, >> schedule training, buy books, buy support contracts, hire >> consultants, etc. In my experience, busy developers are often >> employed by successful companies who have reasonable budgets. If >> the getting started procedure is frustrating, I think they're more >> likely to stop playing with new technology and just continue using >> their current technology (like struts or even pure JSP + >> Servlets), get back to work, etc. >> Currently, GlassFish v3 can be launched from Maven, but it was a >> side project by Koshuke Kawaguchi >> http://weblogs.java.net/blog/2008/04/28/glassfish-v3-just-got-embeddable >> It is not as well documented as Jetty and doesn't auto-deploy >> modified classes. It even shares the same plugin name (but >> different package) as the official Glassfish plugin which controls >> a locally installed plugin, making the plugin very confusing. >> I heard a rumor JBoss is working on an embeddable version of >> JBossAS which will have a maven plugin which will download and run >> a container like the Tomcat plugin. The instant it resembles a >> working product, I'll happily include it in the archetypes as I >> think it'll go a long way towards increasing JEE6 adoption. It'll >> make writing applications much easier for the user and make >> documenting how to get started a breeze for contributers like me. >> Thanks, >> Steven >> >> PS-If anyone hasn't yet used the Tomcat/Jetty/Glassfish plugins, I >> have an old blog post explaining how to use them here: >> http://info.rmatics.org/2009/04/02/increasing-your-productivity-by-using-... >> >> >> >> >> -- >> 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

On Wed, Nov 25, 2009 at 11:44 PM, Steven Boscarine < steven.boscarine(a)childrens.harvard.edu&gt; wrote: > Hello Andrew > I looked at the page, but haven't yet stepped through the source code. > Is there a means of launching the plugin outside of an integration test? > Does this use JBoss6? > JBoss AS embedded is effectively JBoss 6, I'm pretty certain. -Dan > > I am trying to get a JEE equivalent of Jetty's behavior when you launch > 'mvn jetty:run' > Exactly. -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

As of now, EmbeddedAS needs to point to a full Jboss 6.0 installation using ie $JBOSS_HOME. What the "Automation via Maven" wiki explains is how to add a maven dependency so you don't have to pre-install a full jboss, maven will download and unpack it for you. But you still need to bootstap Embedded AS as a part of your test suite. As long as you do that, "mvn test" should work. Arquillian on the other hand does the whole shebang for you.. and then some.. http://www.jboss.org/community/docs/DOC-14376

Dan Allen wrote: > You are correct that for various reasons, many developers are fixated > on Tomcat and Jetty. However, I do believe that if there are > embeddable Java EE alternatives, such as Embedded JBoss AS, then the > grip on servlet containers will loosen. > I agree with Dan very strongly. The sooner there's a JEE6 container that can be launched from maven, like Jetty or Tomcat can now, the "stickier" JEE6 will become and adoption rates will increase. The more steps in an evaluation that cannot be scripted the greater chance that the user will either make a mistake or find something else to do, like get back to work. :) IMO, a key group of developers you'd want to target are very busy people. For many of them, when they are evaluating new software, it is often at the expense of tasks that their management thinks is of higher priority. When they are checking out Weld or JSF2, they're often not doing what their manager wants them to do. If we make evaluating a technology easy and pleasant, I think they'll be more likely to want to go further and adopt the technology, tell their friends, train coworkers, contribute, schedule training, buy books, buy support contracts, hire consultants, etc. In my experience, busy developers are often employed by successful companies who have reasonable budgets. If the getting started procedure is frustrating, I think they're more likely to stop playing with new technology and just continue using their current technology (like struts or even pure JSP + Servlets), get back to work, etc. Currently, GlassFish v3 can be launched from Maven, but it was a side project by Koshuke Kawaguchi http://weblogs.java.net/blog/2008/04/28/glassfish-v3-just-got-embeddable It is not as well documented as Jetty and doesn't auto-deploy modified classes. It even shares the same plugin name (but different package) as the official Glassfish plugin which controls a locally installed plugin, making the plugin very confusing. I heard a rumor JBoss is working on an embeddable version of JBossAS which will have a maven plugin which will download and run a container like the Tomcat plugin. The instant it resembles a working product, I'll happily include it in the archetypes as I think it'll go a long way towards increasing JEE6 adoption. It'll make writing applications much easier for the user and make documenting how to get started a breeze for contributers like me. Thanks, Steven PS-If anyone hasn't yet used the Tomcat/Jetty/Glassfish plugins, I have an old blog post explaining how to use them here: http://info.rmatics.org/2009/04/02/increasing-your-productivity-by-using-... _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Yes, I understand the need for XA enlistment, but JBoss Transactions is already able to do that, right? What I'm saying is that you would use the TransactionalDriver together with a pool. Or does TransactionalDriver already do pooling?

I think we should try and follow the Java EE models as closely as possible for this stuff. We should simply try and make the Java EE code work outside EE 6. e.g. (1) use a resource declaration with @PersistenceContext(unitName=....) to define a managed persistence context (2) use JBoss Transactions to manage transactions in a servlet engine - so instead of having a special tx manager for JDBC, it is just JTA Or is the 10meg download for JBoss Transactions just no good? -- 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

Dan, Personally, I think the most elegant solution in terms of Java EE is simply to standardize "promotable" transactions. Specifically, JTA could be modified to use local transactions by default and only promote transactions to distributed mode as the need arises. The Microsoft guys have had promotable transactions for ages, I am not sure why we don't have it in Java EE too. This would make the "lightweight" vs "heavyweight" debate moot and keep things simple/consistent from a developer's perspective while most of the systems-level issues are dealt by the container where these things belong instead of a steady leak as a development concern.

This is a good idea from a corporate developer's perspective anyways. JEE platform needs to keep things as simple as possible (esp. in terms of configuration) for the typical JEE dev. "Promotable transactions optimize distributed transactions by deferring the creation of a distributed transaction until it is needed. If only one resource manager is required, no distributed transaction occurs." src: http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx Instead of focusing on how "apparently" bad the Spring stack is, I would recommend focusing on expanding on the good ideas that .NET platform has (like the late addition of MVC frmwk in ASP.NET!) Corporate devs are looking to design and code use cases easily/ quickly and not worry too much about system level issues, clustering and lack of tooling, etc. An integrated solution like .NET with the .NET Visual Studio IDE is very attractive (although somewhat limiting perhaps b/c the APIs/frmwks are "locked" down). We have to make way too many decisions about what frmwks and libraries to use in JEE (this problem seems to always be getting worse as the years go by unfortunately). On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: Dan, Personally, I think the most elegant solution in terms of Java EE is simply to standardize "promotable" transactions. Specifically, JTA could be modified to use local transactions by default and only promote transactions to distributed mode as the need arises. The Microsoft guys have had promotable transactions for ages, I am not sure why we don't have it in Java EE too. This would make the "lightweight" vs "heavyweight" debate moot and keep things simple/consistent from a developer's perspective while most of the systems-level issues are dealt by the container where these things belong instead of a steady leak as a development concern. Cheers, Reza Dan Allen wrote: > I was talking to someone about this topic post-Devoxx. I came up with > an idea that may be worth considering. Perhaps the Java EE platform > can recognize another class of bean that has persistence and > transaction capabilities, but not the rest of EJB. Here's my proposed > breakdown, in terms of airplane seat classes (I was on an airplane at > the time). > > First class - EJB session bean > Business class - local transactional bean > Coach - Simple managed bean > > The main differientiator of a "business class bean" from an EJB is > that it would have the option to use local transactions, just like an > application-managed JPA persistence unit. It would also not support > any HA concerns. But it would be a drop in replacement for so-called > "lightweight" transaction beans that Spring offers. > > Then, we wouldn't need to do anything special in Weld / Seam 3. All we > would need is to be able to support these types of beans in a servlet > container, the same way that Weld supports those environments. But it > would be a standard part of Java EE (6 MR1 or 7). > > If we feel like we need to support this use case in Seam, then clearly > there is still something missing in Java EE. > > -Dan > > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King <gavin.king(a)gmail.com > <mailto:gavin.king@gmail.com>> wrote: > > I think we should try and follow the Java EE models as closely as > possible for this stuff. We should simply try and make the Java EE > code work outside EE 6. > > e.g. > > (1) use a resource declaration with @PersistenceContext(unitName=....) > to define a managed persistence context > (2) use JBoss Transactions to manage transactions in a servlet engine > - so instead of having a special tx manager for JDBC, it is just JTA > > Or is the 10meg download for JBoss Transactions just no good? > > -- > Gavin King > gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > -- > 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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

From what I understand, this is an optimization that almost all sane

Transaction Managers do not engage in distributed transactions if there is a single resource and that happens automatically. JTA != 2PC. Jonathan, correct me if I'm wrong, but I'm sure that's something you guys have had in the product virtually for ever. On 24 nov. 09, at 18:18, Arbi Sookazian wrote: > This is a good idea from a corporate developer's perspective > anyways. JEE platform needs to keep things as simple as possible > (esp. in terms of configuration) for the typical JEE dev. > > "Promotable transactions optimize distributed transactions by > deferring the creation of a distributed transaction until it is > needed. If only one resource manager is required, no distributed > transaction occurs." > > src: http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx > > Instead of focusing on how "apparently" bad the Spring stack is, I > would recommend focusing on expanding on the good ideas that .NET > platform has (like the late addition of MVC frmwk in ASP.NET > <http://ASP.NET>!) > > Corporate devs are looking to design and code use cases > easily/quickly and not worry too much about system level issues, > clustering and lack of tooling, etc. An integrated solution like > .NET with the .NET Visual Studio IDE is very attractive (although > somewhat limiting perhaps b/c the APIs/frmwks are "locked" down). > > We have to make way too many decisions about what frmwks and > libraries to use in JEE (this problem seems to always be getting > worse as the years go by unfortunately). > > On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman <reza_rahman(a)lycos.com > <mailto:reza_rahman@lycos.com>> wrote: > > Dan, > > Personally, I think the most elegant solution in terms of Java EE is > simply to standardize "promotable" transactions. Specifically, > JTA could > be modified to use local transactions by default and only promote > transactions to distributed mode as the need arises. The > Microsoft guys > have had promotable transactions for ages, I am not sure why we don't > have it in Java EE too. This would make the "lightweight" vs > "heavyweight" debate moot and keep things simple/consistent from a > developer's perspective while most of the systems-level issues > are dealt > by the container where these things belong instead of a steady > leak as a > development concern. > > Cheers, > Reza > > > Dan Allen wrote: > > I was talking to someone about this topic post-Devoxx. I came > up with > > an idea that may be worth considering. Perhaps the Java EE platform > > can recognize another class of bean that has persistence and > > transaction capabilities, but not the rest of EJB. Here's my > proposed > > breakdown, in terms of airplane seat classes (I was on an > airplane at > > the time). > > > > First class - EJB session bean > > Business class - local transactional bean > > Coach - Simple managed bean > > > > The main differientiator of a "business class bean" from an EJB is > > that it would have the option to use local transactions, just > like an > > application-managed JPA persistence unit. It would also not support > > any HA concerns. But it would be a drop in replacement for > so-called > > "lightweight" transaction beans that Spring offers. > > > > Then, we wouldn't need to do anything special in Weld / Seam 3. > All we > > would need is to be able to support these types of beans in a > servlet > > container, the same way that Weld supports those environments. > But it > > would be a standard part of Java EE (6 MR1 or 7). > > > > If we feel like we need to support this use case in Seam, then > clearly > > there is still something missing in Java EE. > > > > -Dan > > > > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King > <gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> > > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>> wrote: > > > > I think we should try and follow the Java EE models as > closely as > > possible for this stuff. We should simply try and make the > Java EE > > code work outside EE 6. > > > > e.g. > > > > (1) use a resource declaration with > @PersistenceContext(unitName=....) > > to define a managed persistence context > > (2) use JBoss Transactions to manage transactions in a > servlet engine > > - so instead of having a special tx manager for JDBC, it is > just JTA > > > > Or is the 10meg download for JBoss Transactions just no good? > > > > -- > > Gavin King > > gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > > http://in.relation.to/Bloggers/Gavin > > http://hibernate.org > > http://seamframework.org > > _______________________________________________ > > weld-dev mailing list > > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > > > > > > -- > > 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 <mailto:weld-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/weld-dev > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/weld-dev ------------------------------------------------------------------------ _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Hi; Actually one-phase commit optimization is required for the Transaction Managers. See JCA 1.6 --> Section 7.6.3.3 --Gurkan ------------------------------------------------------------------------ *From:* Reza Rahman <reza_rahman(a)lycos.com&gt; *To:* Weld-Dev <weld-dev(a)lists.jboss.org&gt; *Sent:* Tue, November 24, 2009 8:47:32 PM *Subject:* Re: [weld-dev] persistence and transactions outside Java EE Emmanuel, From what I understand, this is an optimization that almost all sane JTA providers have but it is not standards defined behavior. Also, I think a sane JTA transaction manager could work with a non-XA resource in optimized/local mode (again something I think could be defined at the spec level but isn't). I'm looking into some of these issues myself vis-a-vis Resin's transaction manager and am thinking this could be a valuable blog topic to help clear the air on some of this... Cheers, Reza Emmanuel Bernard wrote: > Transaction Managers do not engage in distributed transactions if > there is a single resource and that happens automatically. > JTA != 2PC. > Jonathan, correct me if I'm wrong, but I'm sure that's something you > guys have had in the product virtually for ever. > > On 24 nov. 09, at 18:18, Arbi Sookazian wrote: > >> This is a good idea from a corporate developer's perspective >> anyways. JEE platform needs to keep things as simple as possible >> (esp. in terms of configuration) for the typical JEE dev. >> >> "Promotable transactions optimize distributed transactions by >> deferring the creation of a distributed transaction until it is >> needed. If only one resource manager is required, no distributed >> transaction occurs." >> >> src: http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx >> >> Instead of focusing on how "apparently" bad the Spring stack is, I >> would recommend focusing on expanding on the good ideas that .NET >> platform has (like the late addition of MVC frmwk in ASP.NET >> <http://ASP.NET>!) >> >> Corporate devs are looking to design and code use cases >> easily/quickly and not worry too much about system level issues, >> clustering and lack of tooling, etc. An integrated solution like >> .NET with the .NET Visual Studio IDE is very attractive (although >> somewhat limiting perhaps b/c the APIs/frmwks are "locked" down). >> >> We have to make way too many decisions about what frmwks and >> libraries to use in JEE (this problem seems to always be getting >> worse as the years go by unfortunately). >> >> On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman <reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com> >> <mailto:reza_rahman@lycos.com <mailto:reza_rahman@lycos.com>>> wrote: >> >> Dan, >> >> Personally, I think the most elegant solution in terms of Java EE is >> simply to standardize "promotable" transactions. Specifically, >> JTA could >> be modified to use local transactions by default and only promote >> transactions to distributed mode as the need arises. The >> Microsoft guys >> have had promotable transactions for ages, I am not sure why we don't >> have it in Java EE too. This would make the "lightweight" vs >> "heavyweight" debate moot and keep things simple/consistent from a >> developer's perspective while most of the systems-level issues >> are dealt >> by the container where these things belong instead of a steady >> leak as a >> development concern. >> >> Cheers, >> Reza >> >> >> Dan Allen wrote: >> > I was talking to someone about this topic post-Devoxx. I came >> up with >> > an idea that may be worth considering. Perhaps the Java EE platform >> > can recognize another class of bean that has persistence and >> > transaction capabilities, but not the rest of EJB. Here's my >> proposed >> > breakdown, in terms of airplane seat classes (I was on an >> airplane at >> > the time). >> > >> > First class - EJB session bean >> > Business class - local transactional bean >> > Coach - Simple managed bean >> > >> > The main differientiator of a "business class bean" from an EJB is >> > that it would have the option to use local transactions, just >> like an >> > application-managed JPA persistence unit. It would also not support >> > any HA concerns. But it would be a drop in replacement for >> so-called >> > "lightweight" transaction beans that Spring offers. >> > >> > Then, we wouldn't need to do anything special in Weld / Seam 3. >> All we >> > would need is to be able to support these types of beans in a >> servlet >> > container, the same way that Weld supports those environments. >> But it >> > would be a standard part of Java EE (6 MR1 or 7). >> > >> > If we feel like we need to support this use case in Seam, then >> clearly >> > there is still something missing in Java EE. >> > >> > -Dan >> > >> > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King >> <gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> >> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>>> wrote: >> > >> > I think we should try and follow the Java EE models as >> closely as >> > possible for this stuff. We should simply try and make the >> Java EE >> > code work outside EE 6. >> > >> > e.g. >> > >> > (1) use a resource declaration with >> @PersistenceContext(unitName=....) >> > to define a managed persistence context >> > (2) use JBoss Transactions to manage transactions in a >> servlet engine >> > - so instead of having a special tx manager for JDBC, it is >> just JTA >> > >> > Or is the 10meg download for JBoss Transactions just no good? >> > >> > -- >> > Gavin King >> > gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> >> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>> >> > http://in.relation.to/Bloggers/Gavin >> > http://hibernate.org >> > http://seamframework.org >> > _______________________________________________ >> > weld-dev mailing list >> > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> >> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>> >> > https://lists.jboss.org/mailman/listinfo/weld-dev >> > >> > >> > >> > >> > -- >> > 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 <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> >> > https://lists.jboss.org/mailman/listinfo/weld-dev >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/weld-dev > > ------------------------------------------------------------------------ > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/weld-dev

We actually have parallel conversations going here. Putting aside the question of JTA overhead, the main concern is that JTA transactions simply aren't available in a servlet environment (without extra configuration). Hence my idea of having a lightweight transactional bean that makes use of local transactions rather than requiring JTA transactions provided by an EJB (or EJB lite) container. Or perhaps, it's all unnecessary and we just tell people to use EJB lite if they want transactions and persistence. -Dan On Tue, Nov 24, 2009 at 2:49 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: > > Gurkan, > > Thanks for that...reading through JTA/JCA has been on my wish-list for a > while, I just haven't gotten around to it yet - the blog post exploring > JTA performance would have been my final impetus :-). > > So the real overhead of JTA in optimized mode is what exactly (as far as > you know)? > > Cheers, > Reza > > > Gurkan Erdogdu wrote: > > Hi; > > > > Actually one-phase commit optimization is required for the Transaction > > Managers. > > > > See JCA 1.6 --> Section 7.6.3.3 > > > > --Gurkan > > > > ------------------------------------------------------------------------ > > *From:* Reza Rahman <reza_rahman(a)lycos.com&gt; > > *To:* Weld-Dev <weld-dev(a)lists.jboss.org&gt; > > *Sent:* Tue, November 24, 2009 8:47:32 PM > > *Subject:* Re: [weld-dev] persistence and transactions outside Java EE > > > > Emmanuel, > > > > From what I understand, this is an optimization that almost all sane > > JTA providers have but it is not standards defined behavior. Also, I > > think a sane JTA transaction manager could work with a non-XA resource > > in optimized/local mode (again something I think could be defined at the > > spec level but isn't). > > > > I'm looking into some of these issues myself vis-a-vis Resin's > > transaction manager and am thinking this could be a valuable blog topic > > to help clear the air on some of this... > > > > Cheers, > > Reza > > > > > > Emmanuel Bernard wrote: > > > Transaction Managers do not engage in distributed transactions if > > > there is a single resource and that happens automatically. > > > JTA != 2PC. > > > Jonathan, correct me if I'm wrong, but I'm sure that's something you > > > guys have had in the product virtually for ever. > > > > > > On 24 nov. 09, at 18:18, Arbi Sookazian wrote: > > > > > >> This is a good idea from a corporate developer's perspective > > >> anyways.  JEE platform needs to keep things as simple as possible > > >> (esp. in terms of configuration) for the typical JEE dev. > > >> > > >> "Promotable transactions optimize distributed transactions by > > >> deferring the creation of a distributed transaction until it is > > >> needed. If only one resource manager is required, no distributed > > >> transaction occurs." > > >> > > >> src: http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx > > >> > > >> Instead of focusing on how "apparently" bad the Spring stack is, I > > >> would recommend focusing on expanding on the good ideas that .NET > > >> platform has (like the late addition of MVC frmwk in ASP.NET > > >> <http://ASP.NET>!) > > >> > > >> Corporate devs are looking to design and code use cases > > >> easily/quickly and not worry too much about system level issues, > > >> clustering and lack of tooling, etc.  An integrated solution like > > >> .NET with the .NET Visual Studio IDE is very attractive (although > > >> somewhat limiting perhaps b/c the APIs/frmwks are "locked" down). > > >> > > >> We have to make way too many decisions about what frmwks and > > >> libraries to use in JEE (this problem seems to always be getting > > >> worse as the years go by unfortunately). > > >> > > >> On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman <reza_rahman(a)lycos.com > > <mailto:reza_rahman@lycos.com> > > >> <mailto:reza_rahman@lycos.com <mailto:reza_rahman@lycos.com>>> wrote: > > >> > > >>    Dan, > > >> > > >>    Personally, I think the most elegant solution in terms of Java EE > > >> is > > >>    simply to standardize "promotable" transactions. Specifically, > > >>    JTA could > > >>    be modified to use local transactions by default and only promote > > >>    transactions to distributed mode as the need arises. The > > >>    Microsoft guys > > >>    have had promotable transactions for ages, I am not sure why we > > don't > > >>    have it in Java EE too. This would make the "lightweight" vs > > >>    "heavyweight" debate moot and keep things simple/consistent from a > > >>    developer's perspective while most of the systems-level issues > > >>    are dealt > > >>    by the container where these things belong instead of a steady > > >>    leak as a > > >>    development concern. > > >> > > >>    Cheers, > > >>    Reza > > >> > > >> > > >>    Dan Allen wrote: > > >>    > I was talking to someone about this topic post-Devoxx. I came > > >>    up with > > >>    > an idea that may be worth considering. Perhaps the Java EE > > platform > > >>    > can recognize another class of bean that has persistence and > > >>    > transaction capabilities, but not the rest of EJB. Here's my > > >>    proposed > > >>    > breakdown, in terms of airplane seat classes (I was on an > > >>    airplane at > > >>    > the time). > > >>    > > > >>    > First class - EJB session bean > > >>    > Business class - local transactional bean > > >>    > Coach - Simple managed bean > > >>    > > > >>    > The main differientiator of a "business class bean" from an EJB > > >> is > > >>    > that it would have the option to use local transactions, just > > >>    like an > > >>    > application-managed JPA persistence unit. It would also not > > support > > >>    > any HA concerns. But it would be a drop in replacement for > > >>    so-called > > >>    > "lightweight" transaction beans that Spring offers. > > >>    > > > >>    > Then, we wouldn't need to do anything special in Weld / Seam 3. > > >>    All we > > >>    > would need is to be able to support these types of beans in a > > >>    servlet > > >>    > container, the same way that Weld supports those environments. > > >>    But it > > >>    > would be a standard part of Java EE (6 MR1 or 7). > > >>    > > > >>    > If we feel like we need to support this use case in Seam, then > > >>    clearly > > >>    > there is still something missing in Java EE. > > >>    > > > >>    > -Dan > > >>    > > > >>    > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King > > >>    &lt;gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> > > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > > >>    > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> > > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>>> wrote: > > >>    > > > >>    >    I think we should try and follow the Java EE models as > > >>    closely as > > >>    >    possible for this stuff. We should simply try and make the > > >>    Java EE > > >>    >    code work outside EE 6. > > >>    > > > >>    >    e.g. > > >>    > > > >>    >    (1) use a resource declaration with > > >>    @PersistenceContext(unitName=....) > > >>    >    to define a managed persistence context > > >>    >    (2) use JBoss Transactions to manage transactions in a > > >>    servlet engine > > >>    >    - so instead of having a special tx manager for JDBC, it is > > >>    just JTA > > >>    > > > >>    >    Or is the 10meg download for JBoss Transactions just no good? > > >>    > > > >>    >    -- > > >>    >    Gavin King > > >>    >    gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> > > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > > >>    <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> > > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>> > > >>    >    http://in.relation.to/Bloggers/Gavin > > >>    >    http://hibernate.org > > >>    >    http://seamframework.org > > >>    >    _______________________________________________ > > >>    >    weld-dev mailing list > > >>    >    weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > > >>    <mailto:weld-dev@lists.jboss.org > > <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org > > <mailto:weld-dev@lists.jboss.org>>> > > >>    >    https://lists.jboss.org/mailman/listinfo/weld-dev > > >>    > > > >>    > > > >>    > > > >>    > > > >>    > -- > > >>    > 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 <mailto:weld-dev@lists.jboss.org> > > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > > >>    > https://lists.jboss.org/mailman/listinfo/weld-dev > > >> > > >>    _______________________________________________ > > >>    weld-dev mailing list > > >>    weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > > >>    https://lists.jboss.org/mailman/listinfo/weld-dev > > >> > > >> > > >> _______________________________________________ > > >> weld-dev mailing list > > >> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > > >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > weld-dev mailing list > > > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > _______________________________________________ > > weld-dev mailing list > > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev -- 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

Right, but the last time I checked, getting JTA transactions to work in Tomcat or Jetty was a nightmare. And even when they loaded properly, they didn't actually work (rollbacks failed).

So basically, what I'm trying to resolve is what exactly we are providing by emulating Java EE transactions and persistence. I'm just confused where Java EE falls apart that we feel we need to still provide this.

Isn't this the whole idea of EJB lite? And so I ask, why can't we have Java EE lite which supports @TransactionAttribute without having something that is an EJB, yet still stay inside of Java EE?

>>>the main concern is that JTA transactions simply aren't available in a servlet environment (without extra configuration). AFAIK, you can use UserTransaction object

Actually OpenEJB works great as an embeddable. Just dowloand openejb.war, deploy it into tomcat/webapp that is it! You can use all EJB container functionality in your web applications!

Actually the point is that EJB is just a technology related with Java EE distribution model/architecture. Its usage heavily depends on where you would like to use it. If you want to create a (simple) web application that depends on single database resource, maybe it is not necessary to include EJBs into your application. But if you would like to use 2PC (for example, integrating JMS with Databases etc.), to distribute your business code into more than one machine , to integrate with legacy CORBA systems or other messaging systems etc. you could likely to use EJBs in Java EE environment.

But each one has also an advantage or disadvantage? If you look at EJB 3.1 specification, it is very very easy to integrate lots of cool functionality into your application.

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... There's no configuration needed outside the war. ________________________________ From: weld-dev-bounces(a)lists.jboss.org [weld-dev-bounces(a)lists.jboss.org] On Behalf Of Dan Allen [dan.j.allen(a)gmail.com] Sent: Tuesday, November 24, 2009 3:22 PM To: Gurkan Erdogdu Cc: Weld-Dev Subject: Re: [weld-dev] persistence and transactions outside Java EE On Tue, Nov 24, 2009 at 3:17 PM, Gurkan Erdogdu <gurkanerdogdu@yahoo.com<mailto:gurkanerdogdu@yahoo.com>> wrote: >>> the main concern is that JTA transactions simply aren't available in a servlet environment (without extra configuration). >>> AFAIK, you can use UserTransaction object If I download Tomcat or Jetty right now (unless I didn't get the memo) I won't have a UserTransaction. 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. If you can tell me that placing a single JAR file in the container so that EJB lite works, then we have something. -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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

In most cases perhaps not. But what about config required for JBoss and XA/2PC datasources? Isn't that config manually required in foo-xa-ds.xml as well as configuring default tx isolation? http://www.jboss.org/community/wiki/ConfigDataSources <http://%0Awww.jboss.org/community/wiki/ConfigDataSources> <transaction-isolation> - the default transaction isolation of the connection (unspecified means use the default provided by the database): * TRANSACTION_READ_UNCOMMITTED * TRANSACTION_READ_COMMITTED * TRANSACTION_REPEATABLE_READ * TRANSACTION_SERIALIZABLE * TRANSACTION_NONE On Tue, Nov 24, 2009 at 3:53 PM, Reza Rahman <reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com>> wrote: Steven, The difference is that in a Java EE centric environment, there is *no configuration needed period*, inside or outside the WAR to get transactional functionality. Cheers, Reza Boscarine, Steven 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... > > There's no configuration needed outside the war. > ________________________________ > From: weld-dev-bounces(a)lists.jboss.org <mailto:weld-dev-bounces@lists.jboss.org> [weld-dev-bounces(a)lists.jboss.org <mailto:weld-dev-bounces@lists.jboss.org>] On Behalf Of Dan Allen [dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com>] > Sent: Tuesday, November 24, 2009 3:22 PM > To: Gurkan Erdogdu > Cc: Weld-Dev > Subject: Re: [weld-dev] persistence and transactions outside Java EE > > On Tue, Nov 24, 2009 at 3:17 PM, Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com <mailto:gurkanerdogdu@yahoo.com><mailto:gurkanerdogdu@yahoo.com <mailto:gurkanerdogdu@yahoo.com>>> wrote: > >>>> the main concern is that JTA transactions simply aren't available in a servlet environment (without extra configuration). >>>> > AFAIK, you can use UserTransaction object > > If I download Tomcat or Jetty right now (unless I didn't get the memo) I won't have a UserTransaction. > > 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. > > If you can tell me that placing a single JAR file in the container so that EJB lite works, then we have something. > > -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 > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/weld-dev > > > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/weld-dev ------------------------------------------------------------------------ _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

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

We actually have parallel conversations going here. Putting aside the question of JTA overhead, the main concern is that JTA transactions simply aren't available in a servlet environment (without extra configuration). Hence my idea of having a lightweight transactional bean that makes use of local transactions rather than requiring JTA transactions provided by an EJB (or EJB lite) container. Or perhaps, it's all unnecessary and we just tell people to use EJB lite if they want transactions and persistence. -Dan On Tue, Nov 24, 2009 at 2:49 PM, Reza Rahman <reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com>> wrote: Gurkan, Thanks for that...reading through JTA/JCA has been on my wish-list for a while, I just haven't gotten around to it yet - the blog post exploring JTA performance would have been my final impetus :-). So the real overhead of JTA in optimized mode is what exactly (as far as you know)? Cheers, Reza Gurkan Erdogdu wrote: > Hi; > > Actually one-phase commit optimization is required for the Transaction > Managers. > > See JCA 1.6 --> Section 7.6.3.3 > > --Gurkan > > ------------------------------------------------------------------------ > *From:* Reza Rahman <reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com>> > *To:* Weld-Dev <weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > *Sent:* Tue, November 24, 2009 8:47:32 PM > *Subject:* Re: [weld-dev] persistence and transactions outside Java EE > > Emmanuel, > > From what I understand, this is an optimization that almost all sane > JTA providers have but it is not standards defined behavior. Also, I > think a sane JTA transaction manager could work with a non-XA resource > in optimized/local mode (again something I think could be defined at the > spec level but isn't). > > I'm looking into some of these issues myself vis-a-vis Resin's > transaction manager and am thinking this could be a valuable blog topic > to help clear the air on some of this... > > Cheers, > Reza > > > Emmanuel Bernard wrote: > > Transaction Managers do not engage in distributed transactions if > > there is a single resource and that happens automatically. > > JTA != 2PC. > > Jonathan, correct me if I'm wrong, but I'm sure that's something you > > guys have had in the product virtually for ever. > > > > On 24 nov. 09, at 18:18, Arbi Sookazian wrote: > > > >> This is a good idea from a corporate developer's perspective > >> anyways. JEE platform needs to keep things as simple as possible > >> (esp. in terms of configuration) for the typical JEE dev. > >> > >> "Promotable transactions optimize distributed transactions by > >> deferring the creation of a distributed transaction until it is > >> needed. If only one resource manager is required, no distributed > >> transaction occurs." > >> > >> src: http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx > >> > >> Instead of focusing on how "apparently" bad the Spring stack is, I > >> would recommend focusing on expanding on the good ideas that .NET > >> platform has (like the late addition of MVC frmwk in ASP.NET <http://ASP.NET> > >> <http://ASP.NET>!) > >> > >> Corporate devs are looking to design and code use cases > >> easily/quickly and not worry too much about system level issues, > >> clustering and lack of tooling, etc. An integrated solution like > >> .NET with the .NET Visual Studio IDE is very attractive (although > >> somewhat limiting perhaps b/c the APIs/frmwks are "locked" down). > >> > >> We have to make way too many decisions about what frmwks and > >> libraries to use in JEE (this problem seems to always be getting > >> worse as the years go by unfortunately). > >> > >> On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman <reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com> > <mailto:reza_rahman@lycos.com <mailto:reza_rahman@lycos.com>> > >> <mailto:reza_rahman@lycos.com <mailto:reza_rahman@lycos.com> <mailto:reza_rahman@lycos.com <mailto:reza_rahman@lycos.com>>>> wrote: > >> > >> Dan, > >> > >> Personally, I think the most elegant solution in terms of Java EE is > >> simply to standardize "promotable" transactions. Specifically, > >> JTA could > >> be modified to use local transactions by default and only promote > >> transactions to distributed mode as the need arises. The > >> Microsoft guys > >> have had promotable transactions for ages, I am not sure why we > don't > >> have it in Java EE too. This would make the "lightweight" vs > >> "heavyweight" debate moot and keep things simple/consistent from a > >> developer's perspective while most of the systems-level issues > >> are dealt > >> by the container where these things belong instead of a steady > >> leak as a > >> development concern. > >> > >> Cheers, > >> Reza > >> > >> > >> Dan Allen wrote: > >> > I was talking to someone about this topic post-Devoxx. I came > >> up with > >> > an idea that may be worth considering. Perhaps the Java EE > platform > >> > can recognize another class of bean that has persistence and > >> > transaction capabilities, but not the rest of EJB. Here's my > >> proposed > >> > breakdown, in terms of airplane seat classes (I was on an > >> airplane at > >> > the time). > >> > > >> > First class - EJB session bean > >> > Business class - local transactional bean > >> > Coach - Simple managed bean > >> > > >> > The main differientiator of a "business class bean" from an EJB is > >> > that it would have the option to use local transactions, just > >> like an > >> > application-managed JPA persistence unit. It would also not > support > >> > any HA concerns. But it would be a drop in replacement for > >> so-called > >> > "lightweight" transaction beans that Spring offers. > >> > > >> > Then, we wouldn't need to do anything special in Weld / Seam 3. > >> All we > >> > would need is to be able to support these types of beans in a > >> servlet > >> > container, the same way that Weld supports those environments. > >> But it > >> > would be a standard part of Java EE (6 MR1 or 7). > >> > > >> > If we feel like we need to support this use case in Seam, then > >> clearly > >> > there is still something missing in Java EE. > >> > > >> > -Dan > >> > > >> > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King > >> <gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>> > >> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>>>> wrote: > >> > > >> > I think we should try and follow the Java EE models as > >> closely as > >> > possible for this stuff. We should simply try and make the > >> Java EE > >> > code work outside EE 6. > >> > > >> > e.g. > >> > > >> > (1) use a resource declaration with > >> @PersistenceContext(unitName=....) > >> > to define a managed persistence context > >> > (2) use JBoss Transactions to manage transactions in a > >> servlet engine > >> > - so instead of having a special tx manager for JDBC, it is > >> just JTA > >> > > >> > Or is the 10meg download for JBoss Transactions just no good? > >> > > >> > -- > >> > Gavin King > >> > gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>> > >> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>> > <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com> <mailto:gavin.king@gmail.com <mailto:gavin.king@gmail.com>>>> > >> > http://in.relation.to/Bloggers/Gavin > >> > http://hibernate.org > >> > http://seamframework.org > >> > _______________________________________________ > >> > weld-dev mailing list > >> > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>> > >> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>>> > >> > https://lists.jboss.org/m ailman/listinfo/weld-dev <https://lists.jboss.org/mailman/listinfo/weld-dev> > >> > > >> > > >> > > >> > > >> > -- > >> > 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 <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>> > >> > https://lists.jboss.org/mailman/listinfo/weld-dev > >> > >> _______________________________________________ > >> weld-dev mailing list > >> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>> > >> https://lists.jboss.org/mailman/listinfo/weld-dev > >> > >> > >> _______________________________________________ > >> weld-dev mailing list > >> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>> > >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > weld-dev mailing list > > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> <mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/weld-dev -- 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

> It's somewhat related....in terms of Resin, we actually don't have such > a thing as a traditional EJB container - we have "aspects" such as > transactions delivered via meta-data (e.g. @TransactionAttribute), the > aspects are bound to an underlying implementation (e.g. transaction > manager) and can be used in any component model including managed beans > or EJB. The "EJB Lite" distinction is tenuous since you don't really > need to use the EJB component model per se. To be honest, I'm kind of confused myself now. Circling back to my initial argument, the two options we provide in Java EE at this moment are: - a non-transactional "simple" managed bean or, - an EJB session bean (which is, by default, transactional, and more) So if the developer wants a transactional bean without using an EJB container, they have to use some sort of framework (or portable CDI extension) to get it. To me, that is where Java EE falls apart. There needs to be some middle of the road that the developer can get a transactional bean out of the box OR we just need to say, if you want a transactional bean, you have to use EJB w/ at least EJB lite, period. Why isn't the "simple" transactional bean something that Java EE can provide. Clearly a use case is being ignored. -Dan p.s. The "simple" transactional bean would be a bean w/ @TransactionAttribute and somehow @PersistenceContext would be supported on the bean. -- 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

One of the main issues I had with Seam 2.x was the (lack of) tx propagation support options (specifically REQUIRES_NEW and NOT_SUPPORTED) when using @Transactional when compared with EJB3 tx support and Spring tx support. Refer to this thread: http://sfwk.org/Community/TransactionalPropagationTypes and this: https://jira.jboss.org/jira/browse/JBSEAM-595 and this: https://jira.jboss.org/jira/browse/JBSEAM-4391 AFAIK this is not fixed and/or released.  Will this be fixed and released with Seam3? On Tue, Nov 24, 2009 at 12:44 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > > Btw, this is exactly why most people use Seam 2. They don't want to deal > with EJB. They can just annotate with @Name and inject a Seam-managed > persistence context. The transactions are hooked into whatever they want: > local, JTA or Spring. It's "the hell with EJB" approach. > > I'm just saying perhaps we can find a way to cater to this approach in > Java EE so we don't lose those people to the platform. > > -Dan > > On Tue, Nov 24, 2009 at 3:41 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: >> >>> >>> It's somewhat related....in terms of Resin, we actually don't have such >>> a thing as a traditional EJB container - we have "aspects" such as >>> transactions delivered via meta-data (e.g. @TransactionAttribute), the >>> aspects are bound to an underlying implementation (e.g. transaction >>> manager) and can be used in any component model including managed beans >>> or EJB. The "EJB Lite" distinction is tenuous since you don't really >>> need to use the EJB component model per se. >> >> To be honest, I'm kind of confused myself now. Circling back to my >> initial argument, the two options we provide in Java EE at this moment are: >> >> - a non-transactional "simple" managed bean or, >> - an EJB session bean (which is, by default, transactional, and more) >> >> So if the developer wants a transactional bean without using an EJB >> container, they have to use some sort of framework (or portable CDI >> extension) to get it. To me, that is where Java EE falls apart. There needs >> to be some middle of the road that the developer can get a transactional >> bean out of the box OR we just need to say, if you want a transactional >> bean, you have to use EJB w/ at least EJB lite, period. >> >> Why isn't the "simple" transactional bean something that Java EE can >> provide. Clearly a use case is being ignored. >> >> -Dan >> >> p.s. The "simple" transactional bean would be a bean w/ >> @TransactionAttribute and somehow @PersistenceContext would be supported on >> the bean. >> >> -- >> 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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Yep, the spec states: 'In a Java EE implementation, a Managed Bean may use any of the resource injection functionality laid out in Chapter 5 of the Java EE Platform specification, “Resources, Naming and Injection“.' Hmm, but the trouble is, where does that leave Tomcat and Jetty? And if the resource like the persistence context or UT is to be injected, who is doing the injecting? Of course, if EJB lite were present, it could handle it. So basically, what I'm getting at is that perhaps CDI can provide this transaction and persistence support (maybe even the resource injection) when the Java EE environment is not present (meaning EJB lite is also absent). Of course, we can prototype this as a portable extension today. I'm certainly not opposed to that. But I would hope if we did, the long term goal would be to somehow provide this in Java EE lite. I understand this argument is circular, because eventually you arrive back at the question "why not just make them use Java EE?" The idea is to attract developers to Java EE by giving them one more stepping stone. -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

Sigh. I still feel like we are stuck. I'm hearing that we can either have developers use EJB (lite or full Java EE) or they have to go find a framework to have transactional beans. Maybe in the future this will be in Java EE, but today we have to go about it our own way. And the divergence is what bothers me. If I had to sell this thing to an audience today, I would basically lobby hard for the use of an EJB w/ EJB lite because the alternative sounds too proprietary for me. -Dan On Tue, Nov 24, 2009 at 4:17 PM, Reza Rahman <reza_rahman(a)lycos.com <mailto:reza_rahman@lycos.com>> wrote: Dan, I think the idea of using EJB "aspects" outside the component model is something Java EE will accommodate soon anyway. The solution for now should probably be implementing embeddable containers that way right now. In our case, we still use @TransactionAttribute, but maybe you guys could use @Transactional or something similar... Cheers, Reza Dan Allen wrote: > Yep, the spec states: > > 'In a Java EE implementation, a Managed Bean may use any of the > resource injection functionality laid out in Chapter 5 of the Java EE > Platform specification, “Resources, Naming and Injection“.' > > Hmm, but the trouble is, where does that leave Tomcat and Jetty? And > if the resource like the persistence context or UT is to be injected, > who is doing the injecting? Of course, if EJB lite were present, it > could handle it. > > So basically, what I'm getting at is that perhaps CDI can provide this > transaction and persistence support (maybe even the resource > injection) when the Java EE environment is not present (meaning EJB > lite is also absent). > > Of course, we can prototype this as a portable extension today. I'm > certainly not opposed to that. But I would hope if we did, the long > term goal would be to somehow provide this in Java EE lite. > > I understand this argument is circular, because eventually you arrive > back at the question "why not just make them use Java EE?" The idea is > to attract developers to Java EE by giving them one more stepping stone. > > -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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/weld-dev -- 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

Look, Dan, trust me, I would have tried to push to have support for declarative tx management for managed beans in EE 6, but frankly I already used up every drop of political capital and then some to just get managed beans with interceptors and dependency injection in. Now that we have that much, we have a foundation for generalizing declarative transactions next time around. But we could easily have ended up with no managed beans at all. So you should be thankful for what you *do* have.

On 24 Nov 2009, at 20:47, Gavin King wrote: > Dan, managed beans already support PC injection. I have to check, but I think they can even inject a UT. The only thing they don't have is declarative tx management. This certainly works in JBoss AS right now.

Transaction Managers do not engage in distributed transactions if there is a single resource and that happens automatically. JTA != 2PC. Jonathan, correct me if I'm wrong, but I'm sure that's something you guys have had in the product virtually for ever. On 24 nov. 09, at 18:18, Arbi Sookazian wrote: > This is a good idea from a corporate developer's perspective > anyways. JEE platform needs to keep things as simple as possible > (esp. in terms of configuration) for the typical JEE dev. > > "Promotable transactions optimize distributed transactions by > deferring the creation of a distributed transaction until it is > needed. If only one resource manager is required, no distributed > transaction occurs." > > src: http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx > > Instead of focusing on how "apparently" bad the Spring stack is, I > would recommend focusing on expanding on the good ideas that .NET > platform has (like the late addition of MVC frmwk in ASP.NET!) > > Corporate devs are looking to design and code use cases easily/ > quickly and not worry too much about system level issues, > clustering and lack of tooling, etc. An integrated solution > like .NET with the .NET Visual Studio IDE is very attractive > (although somewhat limiting perhaps b/c the APIs/frmwks are > "locked" down). > > We have to make way too many decisions about what frmwks and > libraries to use in JEE (this problem seems to always be getting > worse as the years go by unfortunately). > > On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman > <reza_rahman(a)lycos.com&gt; wrote: > Dan, > > Personally, I think the most elegant solution in terms of Java EE is > simply to standardize "promotable" transactions. Specifically, JTA > could > be modified to use local transactions by default and only promote > transactions to distributed mode as the need arises. The Microsoft > guys > have had promotable transactions for ages, I am not sure why we don't > have it in Java EE too. This would make the "lightweight" vs > "heavyweight" debate moot and keep things simple/consistent from a > developer's perspective while most of the systems-level issues are > dealt > by the container where these things belong instead of a steady leak > as a > development concern. > > Cheers, > Reza > > > Dan Allen wrote: > > I was talking to someone about this topic post-Devoxx. I came up > with > > an idea that may be worth considering. Perhaps the Java EE platform > > can recognize another class of bean that has persistence and > > transaction capabilities, but not the rest of EJB. Here's my > proposed > > breakdown, in terms of airplane seat classes (I was on an > airplane at > > the time). > > > > First class - EJB session bean > > Business class - local transactional bean > > Coach - Simple managed bean > > > > The main differientiator of a "business class bean" from an EJB is > > that it would have the option to use local transactions, just > like an > > application-managed JPA persistence unit. It would also not support > > any HA concerns. But it would be a drop in replacement for so- > called > > "lightweight" transaction beans that Spring offers. > > > > Then, we wouldn't need to do anything special in Weld / Seam 3. > All we > > would need is to be able to support these types of beans in a > servlet > > container, the same way that Weld supports those environments. > But it > > would be a standard part of Java EE (6 MR1 or 7). > > > > If we feel like we need to support this use case in Seam, then > clearly > > there is still something missing in Java EE. > > > > -Dan > > > > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King <gavin.king(a)gmail.com > > <mailto:gavin.king@gmail.com>> wrote: > > > > I think we should try and follow the Java EE models as > closely as > > possible for this stuff. We should simply try and make the > Java EE > > code work outside EE 6. > > > > e.g. > > > > (1) use a resource declaration with @PersistenceContext > (unitName=....) > > to define a managed persistence context > > (2) use JBoss Transactions to manage transactions in a > servlet engine > > - so instead of having a special tx manager for JDBC, it is > just JTA > > > > Or is the 10meg download for JBoss Transactions just no good? > > > > -- > > Gavin King > > gavin.king(a)gmail.com <mailto:gavin.king@gmail.com> > > http://in.relation.to/Bloggers/Gavin > > http://hibernate.org > > http://seamframework.org > > _______________________________________________ > > weld-dev mailing list > > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > > > > > > -- > > 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 > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

I don't see why would want to introduce a new kind of thing. Just let managed beans have declarative txns. Sent from my iPhone On Nov 24, 2009, at 11:37 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: I was talking to someone about this topic post-Devoxx. I came up with an idea that may be worth considering. Perhaps the Java EE platform can recognize another class of bean that has persistence and transaction capabilities, but not the rest of EJB. Here's my proposed breakdown, in terms of airplane seat classes (I was on an airplane at the time). First class - EJB session bean Business class - local transactional bean Coach - Simple managed bean The main differientiator of a "business class bean" from an EJB is that it would have the option to use local transactions, just like an application-managed JPA persistence unit. It would also not support any HA concerns. But it would be a drop in replacement for so-called "lightweight" transaction beans that Spring offers. Then, we wouldn't need to do anything special in Weld / Seam 3. All we would need is to be able to support these types of beans in a servlet container, the same way that Weld supports those environments. But it would be a standard part of Java EE (6 MR1 or 7). If we feel like we need to support this use case in Seam, then clearly there is still something missing in Java EE. -Dan On Wed, Nov 18, 2009 at 6:10 PM, Gavin King < <gavin.king(a)gmail.com&gt; gavin.king(a)gmail.com&gt; wrote: > I think we should try and follow the Java EE models as closely as > possible for this stuff. We should simply try and make the Java EE > code work outside EE 6. > > e.g. > > (1) use a resource declaration with @PersistenceContext(unitName=....) > to define a managed persistence context > (2) use JBoss Transactions to manage transactions in a servlet engine > - so instead of having a special tx manager for JDBC, it is just JTA > > Or is the 10meg download for JBoss Transactions just no good? > > -- > Gavin King > <gavin.king@gmail.com&gt;gavin.king(a)gmail.com > <http://in.relation.to/Bloggers/Gavin> > http://in.relation.to/Bloggers/Gavin > <http://hibernate.org>http://hibernate.org > <http://seamframework.org>http://seamframework.org > _______________________________________________ > weld-dev mailing list > <weld-dev@lists.jboss.org&gt;weld-dev(a)lists.jboss.org > <https://lists.jboss.org/mailman/listinfo/weld-dev> > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 <http://mojavelinux.com>http://mojavelinux.com <http://mojavelinux.com/seaminaction>http://mojavelinux.com/seaminaction <http://www.google.com/profiles/dan.j.allen> 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