Java EE Containers - Heaven or Hell?

Discussions

News: Java EE Containers - Heaven or Hell?

  1. Java EE Containers - Heaven or Hell? (21 messages)

    ZeroTurnaround has released the results of their "Java EE Containers - Heaven or Hell" survey. Using responses from 700 respondents, they cover topics such as: containers most often used on large projects, fastest container, redeploy times and annual costs of redeployment in a series of charts and calculations. Both the charts and raw data are made available for your own analysis. http://www.zeroturnaround.com/blog/java-ee-container-heaven-hell-survey-results/

    Threaded Messages (21)

  2. To me they are definitely heaven. My definition of hell is a custom Tomcat installation to which JPA/Hibernate has been added in some version, then JSF and JSTL has been added in some version, then some JTA implementation has been added also in some version and with some 'luck' a dozen of other libraries haven been added. Of course, all of these don't consist out of one jar, but of some 6 jars or more. Suddenly you find things like jgroups.jar in your classpath and asm.jar and dom4j.jar and have no idea where those jars originally came from and whether you should upgrade them or not. Then you are tasked to upgrade "Hibernate", but Hibernate has 'contributed' some 12 jars to your project. Which ones did I exactly add? Is other code already using these too? Do I have shared dependencies? With a Java EE container all of this has been sorted out for you already and you just update "Jboss" or "Glassfish" when the time is there. To me Java EE containers are very much like Linux distributions. Only the absolute die hards build their own distribution from scratch. If you absolutely know what you are doing and have too much time at hand, it may be a good idea. Otherwise you'd better stick with Ubuntu, Debian, RedHat, etc. Also, like with Linux distributions, you can still add your own newer versions of software. Don't like that Ubuntu didn't came with Firefox 3.5? Just add it yourself. Similarly, don't like that Jboss AS comes with quartz 1.5.2 for eternity? Just add the latest quartz 1.6.x yourself. It goes even further than that. Don't like that Debian has open office there by default? A few clicks in synaptic and it's gone. Want it back? Another few clicks and it's there again. Same again in (most) Java EE containers. Don't want JMS? A few clicks or a config file change and it's gone.
  3. The Hibernate mess[ Go to top ]

    TThen you are tasked to upgrade "Hibernate", but Hibernate has 'contributed' some 12 jars to your project. Which ones did I exactly add? Is other code already using these too? Do I have shared dependencies?
    Hibernate is a mess, and it was this mess of .jar files that led me to go with EclipseLink for a recent project.
  4. Good points. We do run our application with Tomcat + add-ons (ActiveMQ, hibernate, etc), or with a container like Weblogic or JBoss. It all depends on the customer's preference. The issue is that with the containers, you get too much. We need to trim them to perform well. So the issue is, do you prefer to add to Tomcat, or remove from a container? My personal preference is to add to Tomcat. It is less work than having to learn all the configuration details of a big product like JBoss 5, Weblogic, etc to be able to remove/deactivate/configure out the features I don't need. But if you can stick to one container (not an option for me), and you like it, then I can see the appeal of that. Regards, Paul Casal Developer - jBilling.com
  5. Jar dependencies and version does not has to be managed by the EE Containers. Just put your jar in your war. Okay, you may have 10 copies of the same jar ? And what ? If one of your apps require v 1.3.2 and is incompatible with 1.5 or more and another one require v1.6 or more of some jar, including the proper jar in both wars will save the problem. And your application will work in all EE containers for all of your clients. JVM version is already a real problem for closed source EE container, don't add jar hell to it.
  6. weblogic numbers are pretty bad ![ Go to top ]

    Good to see glassFish catching up in market share so fast !! It doesnt surprise me that weblogic is slow for start up times, redeploy etc. Weblogic pretty much sucks for memory consumption, time it takes to just get it configured and running ( the whole domain set up etc) and dont forget the whole weblogic.jar which has its own classes which match the sun jdk classes. So you need to play with a lot of class path variables for weblogic to not put its nose in every jar you have. I m glad most of the industry feels the same way ! ( Now weblogic sales guys & developers can start ripping me off :) )
  7. Yes. I think weblogic is (still) the best app. server around.
    It doesnt surprise me that weblogic is slow for start up times, redeploy etc.
    Long time ago i never do development using weblogic. I develop on Jetty/Tomcat and deploy on weblogic, so all of those deployment numbers are just pointless to me. Thanks to spring for that.
    Weblogic pretty much sucks for memory consumption, time it takes to just get it configured and running ( the whole domain set up etc)
    You are kidding right? What kind of configuration are you talking about? A standard domain configuration is up and running in about 2 hours (last time i did it) with JDBC, JMS, 2 node cluster, web proxy. And of course, i am not a weblogic guru or anything close.
    and dont forget the whole weblogic.jar which has its own classes which match the sun jdk classes.
    So you need to play with a lot of class path variables for weblogic to not put its nose in every jar you have.
    Ok. All of those classloading issues are for real. But not exclusive to weblogic. I have had those kind of problems with Websphere, Jboss and Glassfish. Not only the jdk classes, but any other library (xerces, antlr, cglib, etc, etc, etc). But fortunately always exists some kind of filter/parent-last mechanism available which do the trick. By the way, i think containers are heaven when you need the services (JMS, JTA, JNDI, JDBC, JPA, etc.) otherwise a waste of time and effort. Just use it wisely. Regards
  8. Long time ago i never do development using weblogic. I develop on Jetty/Tomcat and deploy on weblogic, so all of those deployment numbers are just pointless to me. Thanks to spring for that.
    That's daring. Tomcat != Weblogic, and it's safe to assume that you won't always see the same behavior between containers. This does make QA a nightmare since you'd now have to determine if it's a bug in code or just a matter of Weblogic vs. Tomcat. Besides, how do you handle services not handled by Tomcat? This isn't an workable solution for folks doing more than web applications. Ryan-
  9. Long time ago i never do development using weblogic. I develop on Jetty/Tomcat and deploy on weblogic, so all of those deployment numbers are just pointless to me. Thanks to spring for that.


    That's daring. Tomcat != Weblogic, and it's safe to assume that you won't always see the same behavior between containers. This does make QA a nightmare since you'd now have to determine if it's a bug in code or just a matter of Weblogic vs. Tomcat. Besides, how do you handle services not handled by Tomcat? This isn't an workable solution for folks doing more than web applications.

    Ryan-
    I think he uses Spring and uses WebLogic as a servlet container. If JMS is used, it's ActiveMQ, not the one going with WebLogic. By the way, I'm working with Spring MVC and ... how complex it is!
  10. Long time ago i never do development using weblogic. I develop on Jetty/Tomcat and deploy on weblogic, so all of those deployment numbers are just pointless to me. Thanks to spring for that.


    That's daring. Tomcat != Weblogic, and it's safe to assume that you won't always see the same behavior between containers. This does make QA a nightmare since you'd now have to determine if it's a bug in code or just a matter of Weblogic vs. Tomcat. Besides, how do you handle services not handled by Tomcat? This isn't an workable solution for folks doing more than web applications.

    Ryan-
    I think he uses Spring and uses WebLogic as a servlet container. If JMS is used, it's ActiveMQ, not the one going with WebLogic.

    By the way, I'm working with Spring MVC and ... how complex it is!
    Almost right! I use spring with specific weblogic context if running on weblogic which uses lookups to obtain weblogic's jms services and if running on Jetty/Tomcat then loads different jms context files that includes embedded activemq broker. So i use the container services wherever i can. And the same goes to JDBC, mail and JTA. In fact is a requirement for this app. to run not just on weblogic, but on websphere, jboss and glassfish. It's kind a mess the multiple application contexts but surely works! The current application i am working on is a transactional intensive financial application not a web one. Regards
  11. By the way, I'm working with Spring MVC and ... how complex it is!
    Really?
  12. Weblogic non-standard?[ Go to top ]

    That's daring. Tomcat != Weblogic, and it's safe to assume that you won't always see the same behavior between containers.
    omg seriously? What happen to write once, run anywhere? I've heard this nonsense before, and outside of custom plugins or something, it's complete BS that sys admins use to mandate red tape for developers. ~99.9% of the functionality is consistent across containers these days, and if QA does find an issue, well then that's their job to do so, right? I'd say though if Weblogic does something different on standard J2EE where code fails there and not on other containers, then Weblogic should be replaced with something more standardized. Of course, if that's not an option, you're off to debug mode.
  13. They are hell, well, maybe not hell completely, but definitely not needed. Someone posted a comment about managing dependencies and just using a web container like tomcat or jetty. That's the beauty of it, you can use hibernate for JPA today, then switch to a different implementation tomorrow, and yet another a year from now. JEE containers don't make it too easy to switch out implementations. You can probably do it in some of them, but why? Managing dependencies is not easy, but maven makes it pretty much a non issue in 90% of the cases. Yes it has it's issue with transitive dependency clashes, etc..., but the same issues exist outside of maven. When I start a project, I create issue some maven commands, add a few dependencies to my POM and start coding. I then build a war and drop it into a web container, can't get any easier than that.
  14. Also, wanted to clarify that by JEE containers, I meant the full JEE container, like JBOSS, etc..., not Tomcat, which is just a web container. I think full JEE containers are a thing of the past, or at least I hope they are and people are realizing that.
  15. Also, wanted to clarify that by JEE containers, I meant the full JEE container, like JBOSS, etc..., not Tomcat, which is just a web container. I think full JEE containers are a thing of the past, or at least I hope they are and people are realizing that.
    Hmm, full Linux distributions are a thing of the past, or at least I hope they are and people are realizing that. Sounds a little awkward, doesn't it? No my friend, building your entire stack from the ground up using tons of different libs from different places and then still claiming your are running on 'lightweight' Tomcat. THAT's a thing of the past. Java EE application servers have become very flexible, very convenient pieces of software. Please don't think that its still 2002 and an expensive, closed source and monolithic Websphere is all there is. Wake up! It's 2009 now and we have multiple free, highly flexible, open source and highly modularized offerings from Jboss (Jboss AS), Sun (Glashfish) and Apache (Geronimo) available. THEY are the future.
  16. Great example... JSF[ Go to top ]

    Personally I'm not a big fan of JEE containers. Sure containers are needed, and they do a great job. But application servers just aren't a good solution. For example, I love the Spring container! We've had big problems with WebSphere and JSF, their implementation isn't very good. And this company wasn't very fast updating to new versions on WebSphere, so we were stuck with an old JSF version. I'd rather import a library (MyFaces for example) and just use whatever version I like.
  17. Mistake in third graph?[ Go to top ]

    I found it funny that WebSphere has less time spend redeploying than WebLogic considering that it has longer redeploy time and same number of redeploys (all considering the charts from the original article). So I redid the numbers for chart 3 (Time spent on redeploys, per hour, with container X) and got this: Jetty: 6.095 Resin: 8.8725 Tomcat: 10.9368 GlassFish: 11.3152 JBoss: 14.0896 WebLogic: 17.353 WebSphere: 18.6662 OC4J: 23.198 JBoss, WebLogic and OC4J numbers are off, the last two by a significant amount. Was the mistake made in calculating data for chart 3 or are charts 1 and 2 incorrect? A separate, even more scary conclusion is that JEE developers lose at least a sixth (or 17%) of their time waiting for redeploys...
  18. Re: Mistake in third graph?[ Go to top ]

    Was the mistake made in calculating data for chart 3 or are charts 1 and 2 incorrect?
    Good catch here - there was an error calculating the data for chart 3. I'm in the process of rebuilding the chart & will post the correct one asap.
  19. Market share surprise[ Go to top ]

    What is a surprise is that WebLogic has a comfortable lead over WebSphere, contrary to the published market share surveys and Oracle merger doom & gloom. And there's another interesting oversight: WebSphere is tagged as "IBM WebSphere 6.x" while plenty of other app servers have multiple versions in the tag. Note that WSAS 7.0 has been out for almost a year and the survey was made late this June. I'll chalk it all up to the OP not being up to date with all the different app server releases and this being a rather pointless web survey anyway.
  20. Re: Market share surprise[ Go to top ]

    WebSphere is tagged as "IBM WebSphere 6.x" while plenty of other app servers have multiple versions in the tag. Note that WSAS 7.0 has been out for almost a year and the survey was made late this June.
    I'll chalk it all up to the OP not being up to date with all the different app server releases and this being a rather pointless web survey anyway.
    There was an option for survey respondents to add any other containers they'd like (as noted after the first chart). Unfortunately, no one (zero people) said they were using WSAS 7.0. It would be nice to see data on that as well though. The survey is still live, and as of this post, now has almost 900 respondents. http://spreadsheets.google.com/viewform?hl=en&formkey=cm1rMHVOZEZBMjdSSUZ2eFJCTXFCT1E6MA..
  21. neither[ Go to top ]

    why does it have to be heaven or hell? i've used a few application servers and only had one real complaint. It requires that i talk to bean counters. changed the number of cpus or cores? go talk to the bean counters. move the application to a different server? go talk to the bean counters. want to run the app locally for development? go talk to the bean counters. want clustering? go talk to the bean counters. And even worse, once a year - the bean counters come and talk to me to see if maybe we need fewer beans this year. now i use tomcat for that simple reason - i don't have to talk to the bean counters. and it works just as well as the application servers. the only complaint i've had with it has been the xml libraries are finicky. ok. i'm lying. i actively hated the sun application server version 8 and 9.
  22. 2 cents...[ Go to top ]

    My initial statement, J2EE containers are hell. Period. They are a necessary evil for me to get work done. SUN messed this up from the start by defining web.xml etc for the application level, but nothing for configuration on the app server level. So everyone does it differently: total PITA for developers. On the results, skeptical. First you included Tomcat which isn't a J2EE container. Second... Jetty is faster than resin? Resin is the mostly widely used JSP engine in the world, and there's a good reason for that. You might want to run those tests again. Other than that though, good info.