问题
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?
回答1:
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.
回答2:
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.
回答3:
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
回答4:
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.
回答5:
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.
回答6:
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.
回答7:
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.
来源：https://stackoverflow.com/questions/11262617/why-choose-tomcat-over-a-java-ee-compliant-application-server