Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Java EE on tomcat? Date: Wed, 21 Sep 2011 11:19:41 -0700 (PDT) Organization: http://groups.google.com Lines: 102 Message-ID: <12076840.62.1316629181108.JavaMail.geo-discussion-forums@vbac9> References: <4e69368f$0$303$14726298@news.sunsite.dk> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 2620:0:1000:fd42:224:d7ff:fe69:5838 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1316629181 18475 127.0.0.1 (21 Sep 2011 18:19:41 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 21 Sep 2011 18:19:41 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2620:0:1000:fd42:224:d7ff:fe69:5838; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8179 nroberts wrote: > Apparently the decision to move to Tomcat was simply one of > standardization. I think perhaps the decision was made a while back. "Let's standardize on Betamax for our on-demand movie streaming service." Standardization is good as long as the standard actually applies to the pro= blem domain. > At any rate it was made without me for reasons I do not know. I was > told though, when I mentioned being worried that such limits could > increase development effort, that I can use whatever libraries or > extensions I need. This includes things like OpenEJB etc... As others pointed out, this is not a good approach. If you need all those = things, better to go with Glassfish or Geronimo or JBoss where it's already= all there, and just about as lightweight as Tomcat without those things. > After learning more about these buzzwords and what they actually > implement though I'm starting to wonder what is left for EJB. I can > replace standard Java EE JPA with Hibernate as it implements it now. Wrong direction. Standard JPA replaces the old-style Hibernate way. Since Hibernate directly supports JPA, why would you even remotely consider= doing that the ass-backwards way? Use Hibernate, sure, but use it *as a JPA provider*. Using "raw" Hibernate= leads to trouble. You wouldn't think so, but it does. Every single time = I've seen Hibernate in the wild, it's used wrong. Monolithic 'Session' obj= ects, inappropriate calls across message queues, direct references to table= surrogate keys (auto-generated integer IDs, if you can believe it!) in the= object code, strange manipulations of under-the-hood SQL - I've seen so ma= ny crazy things in Hibernate-based applications. =20 Using it as a JPA provider (strictly) leads to gentler idioms. Short-lived= 'EntityManager' instances, dependency injection, objects that reference ot= her objects (or collections thereof), not their keys - the benefits accrue.= =20 Use the JPA mode. > I can pull in JSF with either the standard implementation or MyFaces > (and tobago or whatever looks pretty interesting). I can get That's not EJB - that is Web. Tomcat supports JSF quite nicely. > dependency injection with CDI; I'm thinking this gives me all the Some things are just easier in an enterprise application server than a web = application server, but you're right, Tomcat suffices for a broad category = of needs. Until it doesn't. > advances in unit testing that EJB 3.1 gave us. I can get @WebService > with JAX-WS though I might not even want it. >=20 > Unfortunately, if I use OpenEJB I'm stuck with an older Tomcat as it > doesn't work with 7.0 yet. I tried a patched version that someone > released and it kind of worked I thought, but yesterday I found that > webservices were bugging out...either that or need a totally different > way of setting them up that would likely be a nightmare to figure > out. I spent a good day on it yesterday just trying to get the ejb > example webservices to work and the way I fixed it was to stop trying > to use a patched version and just downgrade Tomcat. Don't use OpenEJB. Don't use EJBs at all. > I'd rather not base a new project on old technology that's just going > to end up obsolete the next release if I can at all help it. >=20 > Another thing about the previous technologies I listed is that I can > put them in my app's WEB-INF folder; I don't have to install them in > Tomcat. Perhaps OpenEJB is the same way but I've not seen clear > documentation on doing so. Putting "them in [your] app's WEB-INF folder" is not the right way to deplo= y applications. Oh, wait, you mean "deploy in your application's WAR file"= . Okay, that's all right. Your terminology confused me for a second. > What is it that EJB offers me that I don't get with these other > standard technologies? I thought it was things like SessionBeans and > such, but if I use the CDI and JSF bits it seems like I get a lot of > the same behavior because I've got @ManagedBean or @Named. I'm > finding this confusing. ManagedBean and SessionBean are not the same thing. JSF is a front-end technology. EJB is a middleware technology. Different = layers with different purposes. That the behaviors are similar is a help to learning them, but do not make = the mistake of thinking that that makes them the same thing. They are not. That said, you should avoid EJBs at first anyway. Write web apps for a whi= le until you know what you are doing. --=20 Lew