39

Java EE application servers provide all the features of tomcat, so why use tomcat (instead of glassfish for example as it is the official one)?

Especially when Java EE features are needed like JPA, JAX-RS, JSF, and therefore more libraries have to be packaged with the application, while a EE-compliant application server would have provided it out of the box?

kgautron
  • 7,915
  • 9
  • 39
  • 60

7 Answers7

83

The question that was in our mind and the entire reason we created TomEE was, why should people have to choose?

The whole "Tomcat or JavaEE" thing is tired and old.

After 10 years it still comes up and people argue against each other as to which is better and why.

Here's the math in short form:

  • In Java EE 6, we (JCP) created the Web Profile to formally acknowledge the need for smaller runtimes with a focused set of technologies.

Great, we're half-way there, but people are still arguing "Tomcat or JavaEE". The solution was clear, Tomcat needed to be Java EE certified. The Web Profile was created to allow for exactly that.

  • In 2011 we (Apache) started doing the work to certify Apache Tomcat. Certification reached and announced at JavaOne 2011 as Apache TomEE. Final release announced in April.

Awesome, now we are there.

The new Status Quo

  • There is a lighter version of JavaEE
  • There is a JavaEE certified version of Tomcat

All this happened in the last 2 years. Things have changed.

If you want Tomcat and JavaEE, you can have it.

Community
  • 1
  • 1
David Blevins
  • 19,178
  • 3
  • 53
  • 68
  • 6
    This is useful information, but I don't feel like it answered the question. Before TomEE, why would people choose Tomcat over a Java EE certified server? I know the whole "Tomcat or JavaEE" thing is tired and old, but I've never seen the discussion. – Daniel Kaplan Jul 08 '14 at 00:01
  • 3
    The answer to that usually was Java EE is "heavy", "overkill", "bloated", "slow", "untestable" and generally sucks and I can build all that myself anyway [on tomcat]. Really what they meant was "the available implementations suck, I can build a better implementation". This is a fair thing to do, just acknowledge that it is Java EE. If you don't like Ford or Chevy it doesn't mean cars suck. If you build a better car, it only proves cars can be good. – David Blevins Aug 21 '14 at 19:23
  • 1
    Here's a 4 page article from 2008 on "Tomcat in the enterprise" if you're interested http://www.javaworld.com/article/2077826/open-source-tools/tomcat-in-the-enterprise.html – David Blevins Aug 21 '14 at 20:22
6

Rarely if ever do people use a plain Tomcat. They always add tons of extra stuff, like a webframework, some orm, some DI framework etc etc.

You could use Spring for this, but the end result will be large, bloated and you'll be forced into a lot of XML programming.

Modern Java EE 6 implementations are very lightweight (TomEE and Resin are only 25mb) and contain everything you need (web, persistence, DI). The so-called Web Profile doesn't contain any stuff that you only rarely need. Modern Java EE 6 servers start up in a second or two, which is in the same league as a bare Tomcat, yet they actually offer the tools you need on a daily basis.

Clafou
  • 15,250
  • 7
  • 58
  • 89
Mike Braun
  • 3,729
  • 17
  • 15
  • 3
    Regarding spring - Spring is modular, and you may choose EXACTLY what you need from it (spring-core, spring-jdbc, spring-mvc) and so on... – Yair Zaslavsky Jun 30 '12 at 16:56
  • 1
    In addition, with today's storage, I think if you place jars of spring-core, spring-jdbc, spring-mvc and other spring jars you carefully pick, the storage overhead required for this is not that big. – Yair Zaslavsky Jun 30 '12 at 16:58
  • 10
    Spring puts the burden of composing a stack on you. It's not optional. Many required parts (like Hibernate or Transactions) aren't even in Spring, so you need to go elsewhere. With Java EE you have a choice between two really good standard profiles (Web and Full), or if you really want to compose your own stack. Everything in Java EE is modular as well. JSF, CDI, EJB, etc etc can all be added individually to Tomcat or Jetty. – Mike Braun Jun 30 '12 at 18:43
  • 5
    Nowadays you can do java configuration with spring, so you don't need to create tons of XMLs. :) Just saying... cheers! – Disper Jan 21 '14 at 13:42
  • @Disper good to hear Spring is following Java EE's lead here ;) – Mike Braun Feb 03 '14 at 09:43
5

Most Java EE application servers are bulky, come with alot of features that are not needed, and have a really slow develop/test cycle (just check the java rebel productivity reports). If you really need some of the Java EE features then you should use it, but most of the cases you can have the same basic features (servlet container essentially, you can put most of Java EE tech on top of a tomcat, such as lightweight ejb container, etc) with tomcat or any other lightweight servlet container.

Also bear in mind that you can use JPA, JSF, JAX-RS outside of an application server.

TL;DR: Java EE application servers are apparently slow, don't reload classes on the fly and force a very irritating code/deploy/test cycle (think anywhere from 20 secs to 8 minutes to test some change within your java code). Most people just need the basic features (servlet container essentially).

Here's a report about redeploy times from 2011: http://zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Miguel Ping
  • 18,082
  • 23
  • 88
  • 136
  • 7
    FYI, the average start time of the latest versions of nearly all the Java EE servers these days is [1-3 seconds](http://antoniogoncalves.org/2011/10/20/o-java-ee-6-application-servers-where-art-thou/). – David Blevins Jun 29 '12 at 13:52
  • 1
    @DavidBlevins that's just incorrect. It's probably the *advertised* time of a fresh install. Here's an accurate report from the jrebel team (2011): http://zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times – Miguel Ping Jun 29 '12 at 14:39
  • 2
    I definitely agree that this is the way it was -- when Arquillian was created it actually used to be demoed with OpenEJB because JBoss was too slow. Since JBoss 7 they now demo with JBoss. Would be great if that JRebel report had the server versions in it. – David Blevins Jun 29 '12 at 15:08
  • Looks like from some of your other answers you might be using JBoss 7.1. What have your impressions been on deploy times? – David Blevins Jun 29 '12 at 15:11
  • IMHO it's WAY better than WebSphere :\ but when you're loading 200+ JPA classes there's no way to be faster :P. JBoss is very very fast regarding deploy times. But once you are used to rails/python/php/whatever stack that requires only a browser refresh everything seems slow by comparison. – Miguel Ping Jun 29 '12 at 17:20
  • 2
    Here's more about the server startup time that we (JRebel team) have been measuring: http://dow.ngra.de/2010/12/14/jee-oss-container-startup-times-apples-vs-oranges/ In fact, server startup time is not the primary problem for the most modern application servers, be it Tomcat or Glassfish. Even WebShpere is now damn fast on startup (see Liberty Profile version). It is the application and framework metadata that takes ages to initialize (say hello to annotation-based programming model). – Anton Arhipov Jun 30 '12 at 04:41
  • 4
    Jboss EAP 6 starts op in 0.8 seconds on my machine. With an app that uses JSF, EJB, CDI and JPA it's 2 seconds. A similar Spring 3.1 app takes almost 10 seconds, who is the lightweight one now huh? – Mike Braun Jun 30 '12 at 14:36
3

As explained above by @Miguel Ping, Application servers contain features developers don't need.
For example, many developers do not need code for messaging , so they don't need JMS jars.
Other developers may not need clustering, so they don't need clustering code, and so on.
As today most UI is oriented towards web, Servlet container, which must be provided by application servers , becomes more and more a crucial component, hence many developers decide to use ONLY a Servlet container (i.e - tomcat).
In this case, many developers use Spring framework to provide replacement for functionality they have with plain Java EE (or to integrate with Java EE - Spring can be run on top of application server as well).
Spring-core is lightware and provides mostly a Depdency Injection/Inversion-Of-Control container (replacing the EJB container at Java EE).
You may add other modules from Spring framework to give more features to your application., whereas in many application servers (those of EJB 3.0 and below) the application server is loading the entire stack and this also affects staring time of Application Server (and this is quite annoying for developers, from personal experience).

Having said that, EJB 3.1 contains now profiles, for example - the web profile, which loads a smaller number of parts from the Java EE spec. In addition, Jboss introduced in JBoss AS 7 a parallel deployment mechanism which analyzes dependencies within application , and performs parallel deployment of independent components.
For example, at oVirt open source project, we reduced start time from more than 1 minute on a simple deployment of a virutalization environment to something like 3 seconds.
I have no idea if such mechanism exist in other EJB 3.1 application servers, however, as mentioned before, you can define profiles quite easily or use already existing profiles, such as web profile (EJB lite) in order to reduce start time


To conclude, In past - people used tomcat mainly to reduce start time and to reduce amount of modules being loaded.
Spring presented a modular alternative to Java EE development and can be used with tomcat.
. Today, with EJB 3.1, Java EE has also adpoted modularization, and there are application servers such as JBoss AS 7 which reduce start time to a few seconds due to all kinds of optimization made during the deployment.

Yair Zaslavsky
  • 4,091
  • 4
  • 20
  • 27
  • That's not true; Java EE application servers, especially the web profile ones, contain exactly those features that every (web) application needs. Tomcat on the other hand is so bare that no modern application runs only on Tomcat without using anything else. – Mike Braun Jun 30 '12 at 15:14
  • It's obvious that you need to run tomcat with a stack besides servlet container. Too bad you did not understand my comment, decided to down vote it. I introduced tomcat + spring as an alternative to Application server, and even to web profile (ejb-lite). – Yair Zaslavsky Jun 30 '12 at 16:54
  • 6
    Your post was a bit incohesive really. It's not "EJB 3.1 application servers", but "Java EE application servers". EJB is just a part of Java EE. Then you say an AS contains things developers don't need and that ONLY a servlet container is enough, only to start some difficult to follow text about Spring being a replacement for functionality in Java EE (so that functionality was appearently needed afterall). – Mike Braun Jun 30 '12 at 17:58
  • 3
    P.s. also note that the few bits on disk taken up by JMS don't have any impact on startup time nor memory usage; all modern Java EE app servers only load what's actually used. Undoubtedly, there are also many classes inside Spring that not every application uses (IMHO there are a lot of those in Spring) – Mike Braun Jun 30 '12 at 18:37
  • 5
    Plenty of FUD in this thread from people who clearly have never used an AS or developed an application that isn't a toy.Glassfish for example only loads the pieces of the stack as they are required. For example, the EJB container won't spin up unless you deploy something with EJBs. Likewise JMS won't spin up unless you deploy something that uses it. Glassfish 3.1.2s pure start time (the time it takes to spin up without a deployed application is in the milliseconds (Windows 7, JDK 7 64 bit VM). – NBW Jul 01 '12 at 03:40
  • "Jboss introduced in JBoss AS 7 a parallel deployment mechanism" : the parallel deployment is in Apache Tomcat 7, not in JBoss AS 7 (sadly). – Julien Kronegg Aug 06 '12 at 13:24
  • Upvoted this! The most common reason I noticed for using fancy, expensive application servers is that people like to put it on their resume. – wavicle Aug 23 '14 at 02:11
3

Tomcat is a well-written light-weight servlet container that does everything needed for a large number of JVM web applications. It works well in production as a web server speaking directly to the browser. For many people, Java EE has too much stuff in it, more than needed to build stable useful applications. This type of person looks for tools that have less, not more, and values stable well-written code above features. The world of software choice is a marketplace, and Tomcat serves a portion of that marketplace very well. Just like in any marketplace, you need to look at the alternatives and choose what meets your needs. Tomcat is just one of many alternatives.

There is an interesting viewpoint of Tomcat in this paper http://www.people.hbs.edu/cbaldwin/DR2/LaMantia-Cai-MacCormack-Rusnak%20WICSA2008.pdf about design structure matrices. They compare it to an unnamed competitor and find it well-designed. If you are interested in analyzing your own code the only DSM implementation that I know if is IntelliJ Enterprise edition but they do give you a few weeks free trial.

Personally, I believe that simplicity is a virtue in support software and the servlet container is support software, not a part of your application.

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106
0

In most cases, the decisions about application server selections (Tomcat vs. AS like JBoss) will be made according to the experience and knowledge of the administration/development team at the small IT departments and IMO it's political than technical issue. Moreover, the projects which are at most deployed on tomcat are often web applications with little integration concepts and complexity. For such projects lightweight containers and frameworks(Spring, Struts) are often employed.But, if the projects are getting complicated and more distributed, the attributes like scalibility, "monitoring", high availibility (like @HASingletons of JBoss), etc. come in place. And it can be then very painful to equip your plain tomcat with 3rd party frameworks to get all features of AS' and most of times you will have challange to get to run all these together.

Erhan Bagdemir
  • 5,231
  • 6
  • 34
  • 40
  • I am going to answer the concerns in using Tomcat in a cloud platform such as Amazon Web Services. Achieving scalability (vertical scale out or horizontal scale up) is possible using more resources. For instance, in AWS it can be done through auto scaling Tomcat instances. Monitoring is a vast area and if we are talking about JVM monitoring it can be achieved using tools. High availability can be achieved using fail-overs and for a Tomcat app in AWS, it is achievable through simple health checks in Route 53. There is'nt anything that prevents an enterprise app to be production ready on Tomcat. – StackOverFlow User Aug 31 '15 at 04:37
0

They think they're choosing to be lightweight but at the end of the day their applications will be far heavier weight than they would be using Java EE web profile. If they opt for spring, their deployments are likely to be very large with slower build and server start-up times. Developer productivity declines ... If you want your app to be as simple and lightweight as it can be, opt for a Java EE server that supports web profile.

John Hogan
  • 152
  • 1
  • 7