Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2578 posts at DZone. You can read more from them at their website. View Full User Profile

In Defense of Tomcat

  • submit to reddit
Sateesh Narahari of MuleSoft says he's cleaning up the FUD he's been hearing from Java EE app server vendors about Tomcat.  As a company that's heavily invested in open source Tomcat products like the Tcat Server management tools (which are free to use in development and pre-production environments), MuleSoft believes a "bloated" JEE app server isn't always the best option.  Most developers should know this because several surveys indicate that Tomcat severs are used in a majority of Java development shops.  Narahari says that vendors stand to lose a lot of business if you move more applications over to Tomcat:

"If you've considered ever considered a move to Apache Tomcat, you may have come across statements like these:

"Tomcat is only good for development; it doesn't perform well in production."

"Tomcat is not proven for use in your vertical - you should be running Java EE app server."

"You won't be able to get any support if you run your applications on Tomcat."

"Tomcat needs to be modified and our forked version of Tomcat is the only one you should use."

"You shouldn't move away from Java EE to Tomcat, you should move to a lightweight Java EE app server."

Narahari then attempts to refute these statements, claim-by-claim:

"What they say: "Tomcat is only good for development - it doesn't perform well in production."

FUD Buster
: This is not correct - several high performing web applications use Tomcat as their app server, including ETrade, WalMart, Cardinal Health, The Weather Channel and more. Anyone saying Tomcat isn’t suited for production use is either uninformed, or giving
you the run-around.  Want more data?  Check out this list of all websites, systems and applications that run on Tomcat, refer to this page on Apache's website. You might need to clear some time out of your schedule, because it's about a mile long.  Case closed!

What they say: "Tomcat is not proven for use in your vertical - you should be running a Java EE app server."

FUD Buster
: Actually, this statement is more of a half-truth. There may be some special situations where a reliance on legacy applications forces you to use a legacy application server.  However, in the majority of mainstream verticals, Tomcat has been proven more than a match for the job, and the proof is available across multiple industries - healthcare providers, auction houses, financial organizations, grocery stores, real estate... It's simply not a matter of debate.  Let's put this myth to rest.  Tomcat is proven in the vertical.

What they say: "You won't be able to get any support if you run your applications on Tomcat."

FUD Buster:   No support?  There several world-class companies, including MuleSoft, that provide first class support for Apache Tomcat. For example, MuleSoft employs a team of Tomcat experts led by Jason Brittain, author of Tomcat 6: The Definitive Guide (O'Reilly), who provide our customers with 24/7 rapid response Apache Tomcat

What they say: "Tomcat needs to be modified and only our version of forked Tomcat is the right one you should use."

FUD Buster
:   As we pointed out above, Tomcat is battle tested and has been used widely in production. If a vendor is telling you to use their forked version of Tomcat, you should be bit concerned about that vendor's true motives.  Vendor lock-in is never a good situation to find yourself in, and that's just what these companies are setting you up for when they try to sell you their "improved" version of Tomcat.  I am not saying Tomcat does not have any wrinkles, but those are minor annoyances when compared to a vendor lock-in situation.  Use a forked version of Tomcat, and you're at the mercy of one vendor for security and bugfix patches, without the ability to upgrade to the latest version of Tomcat on your own.  That’s not help – that’s hurt.

What they say
: "You shouldn't move away from Java EE to Tomcat, you should move to a light weight Java EE app server instead!"

FUD Buster:  Let's get the facts straight.  Using Java EE app servers is proven to be unhealthy for your IT environment.  It increases cost and complexity and puts you on a operational treadmill, leaving very little time to actually run your business.  Java EE includes over 25 technology standards that are designed by armies of committees over years of meetings. However, most web applications do not require more than four or five of these technologies.  When you use Java EE you are paying hefty license fees and jacked up infrastructure costs for features and complexity that you most likely don’t need. Move away from Java EE - there is no such thing as a good lightweight Java EE app server; by definition, any and all Java EE-compliant servers are burdened by the weight of the same bloated committee designed standards.

I'm curious to hear about your experiences dealing with these tactics.  Have you ever been confronted by this or any other FUD from large app server vendors or from people within your own organization who are afraid of change and resist the move to a lightweight applicationserver?"

If you want to find out more about Tomcat's strengths and weaknesses as an application server, check out this article from or MuleSoft's Apache Tomcat Resource Center.


Kristian Rink replied on Fri, 2010/06/11 - 12:42am

It started out goot but ended bad, in the end not being a "FUD buster" but actually spreading FUD itself. Some reasons or questions:

- Java EE app servers "proven to be unhealthy to your IT environment" - by whom?  All the reasoning following this statement (increased cost, increased complexity, ...) are pretty well-known today, yet I'd wait a couple of years to look back at things and see whether "lightweight" solutions to complex problems have been more straightforward. Overally, I've been dealing with quite some Spring projects inside tomcat containers, and, looking at the overall complexity, I hardly would say they're easier. Yes, maybe the container is more lightweight, but that's about it, and this "lightweightness" you pay by not having a real administration environment (that's where JBoss, Glassfish, WebLogic or even Geronimo definitely excel while "plain tomcat" or jetty virtually lack any meaningful administration tool or UI). That's not generally a bad thing, but it might be interesting to consider.

-  Regarding "... most web applications do not require more than four or five of these technologies...": Well, could it be that eventually Java EE initially has been made to do more than just building simple web applications? Yes, if you're just out to do a straightforward web application without thinking too much about things, a Java EE application server might be oversized. So why not look at the problem and choose the right tool for the right purpose rather than doing tool-bashing?

-  Regarding "When you use Java EE you are paying hefty license fees and jacked up infrastructure costs for features and complexity that you most likely don’t need.": At first, you generally will have to make a price-vs.-feature decision, no matter which solution you buy. And then again, what keeps you from goin' with an open-source Java EE server platform and buy support for it if you need it? At the very least for Glassfish and JBoss this is possible pretty easily as far as I know. 

- Regarding "Move away from Java EE - there is no such thing as a good lightweight Java EE app server; by definition, any and all Java EE-compliant servers are burdened by the weight of the same bloated committee designed standards.". I am tempted to say that this is utter nonsense, almost the typical anti-Java-EE-specification rant, and I generally consider any and all technical posts containing the term "bloated" to be sort of off-track as this is by no means unbiased or neutral, technical point of view. And it gives a rather bad name to the definition "lightweight". Doing a very simple comparison: Talking about Java EE, I easily can name at the very least five or six different server implementations supported by different vendors. About Spring, in example, usually being considered the forerunner of lightweight Java EE applications, I see one single "implementation" which in itself has no real specification and, apart from that, also supports a bunch of Java EE technologies. So goin' for Spring tc server for support, in example, am I not all of a sudden at the mercy of "SpringSource, a division of VMWare", having no second option because knowing that in this case it's a _product_ not a _technology_ I bet my fortune on? Don't get me wrong, I am not ranting against Spring, but I think the idea of being to quite some extent vendor-independent (sure it's not 100% or maybe not even 75% but it's still way more compared to other solutions) is the least worst thing about Java EE and something one should take into consideration when thinking about such decisions.  


Ryan Developer replied on Sun, 2010/06/13 - 11:38am

> When you use Java EE you are paying hefty license fees and jacked up infrastructure costs

FUD.  There are a number of excellent free open source Java EE application servers.  JBoss has more market share than any other Java EE application server, and is the same price as Tomcat: free.  Want support?  Lots of free support in forums, or paid support for those who want it. Same with GlassFish.  Other open source options include Resin and Geronimo.

As for jacked up infrastructure costs, maybe you are not aware that GlassFish loads only the features that your deployed applications use into memory.  Don't use JMS?  No JMS will be loaded.  When you undeploy an application, features that are not used by other deployed applications are unloaded.  I don't know for sure, but I think JBoss and Geronimo have similar features.


> for features and complexity that you most likely don’t need.

FUD.  Most non-trivial applications that run on Tomcat or Java EE application servers do need technologies such as RESTful and SOAP web services and the XML parsing & binding that goes with it, dependency injection (contextual or not), object relational mapping, transaction management, jdbc connection pooling, timers, mail, validation, servlets, web framework, security, and sometimes even legacy technologies such as RPC web services, JSP and JSTL.

Java EE users get this functionality out of the box, no integration required.  Use only what you need. As your application matures, more technologies are at your fingertips including non Java EE things such as clustering & high availability. You don't have to use Java EE APIs all together -- you can drop in replacements for anything you want (such as a web framework) while still taking advantage of all the other pre-integrated technologies.

Tomcat users pick and choose a plethora of frameworks and libraries to solve each of these problems individually (aka Tomcat++), then have to deal with the complexities of integrating all of these technologies. No two developers make the same choices of frameworks and libraries, which causes a learning curve (expense) when hiring new employees.

> Using Java EE app servers is proven to be unhealthy for your IT environment.  It increases cost and complexity and puts you on a operational treadmill, leaving very little time to actually run your business

FUD. Stop lying to yourself and everyone else. It is FAR more complex to select and integrate technologies neded by non-trivial applications than it is to use Java EE 6.  Just as a junior developer and you'll see. Tomcat increases cost and complexity, puts you on an operational treadmil, and leaves very little time to actually run your business. Maintaining a Tomcat++ server is like maintaining your own Linux distribution and getting support from all the component vendors individually. Using a Java EE application server is like using a pre-integrated Linux distribution where all your support needs (including upgrades) can be provided by one vendor, if and when necessary, and for free if you use an open source product.

And Bod replied on Fri, 2010/06/11 - 3:12am

Oh this is shuc BS! Another fake I'm all open source framework maker, that really just gives his crap for free just so that he can tie you in and fork your money later on the "enterprise" version. Alfresco does that too, and I've gotta say, after working for month with both these magical pieces of software (Alfresco 3.3 Labs and Mule ESB 2.X) I gotta say they're a crappy bre alpha junk, made with one purpose in mind, to be attached to some crocky marketing campaign and get some money of some idiots (like the company I work for).

You know, all the things this guy sais are bad about non tomcat App servers can just as easily be applied to Mule USB. Vendor lock in? Check. Even tho the POS uses CXF (2.2.1 I think) & Spring (2.5.6( under the hood, you gotta use it's  own fashion of doing things, CXF endpoints are no longer declared as CXF endpoints, and the standard Spring bean context is replaced by mule's own crap. 

Unreliable, check again, I've encountered so many bugs in Mule ESB, i think it aged me 3 years in 3 months. And what's funny is that for a good part of these bugs the answer from Mule is either, "yeah we know of it but we won't fix it" or "wait for a new version and check then". I spent days mixing and matching Mule ESB versions with Spring CXF and other libraries/frameworks, to get the mule server to start.


And about Tomcat, I don't love it or hate it much, but the junk this dude is trying to sell, while adressing developers as well, is quite lame. Sorry sir, the sales dept. is down the hollway, try there. Jboss is just as free and lightweight as Tomcat, and I know for sure, after many many tests that JBoss 4.2.3 has all the facilities of TC 6 (heck it uses TC engine under the hood), and it's faster then TC, doesn't have many of it's bugs (like hot deployment with Struts 1.3 apps). So leave it alone , ok.



Seb Cha replied on Fri, 2010/06/11 - 8:07am

@And Bod

I agree completely on all your statements.

I'm working on Mule since 18 months. I know well its source code and I've done a lot of extensions for it. Mule has a lot of bugs, i had to rewrite transaction code because it doesnt work as expected, it doesnt use Spring Transaction. I had to rewrite the jms code to make it work with websphere. I had to rewrite the servlet code too, because, and it's really really funny, Mule 2.2.1 is not compatible with Tomcat. Yes, the same Tomcat that they try to support. (Tomcat lowercases all http headers, and Mule didnt expect that before Mule3, how it is possible to not have seen it ? no tests ? WTF).

Another thing, the source code quality is crap. Really. Those guys dont know SOLID, pmd, checkstyle, or unit test, and dont even test it. They like 1000 lines code methods. IMO, the worst code i have ever seen.

They use Spring. Yes. But i think they should have understood it before. "the standard Spring bean context is replaced by mule's own crap"  +1.

What about maven dependencies ? => Jar Hell. They dont know maven as well.


Seriously Mule guys, move on, and use Spring Integration insteed. I needed 1 year to understand Mule, and 2 days for Spring integration. Just facts.

Alois Cochard replied on Fri, 2010/06/11 - 8:35am

When you see that very large Documentum installation run smoothly with Tomcat, I wonder how people can say it's not suitable for production environment. You can even make cluster of tomcat server using Tomcat and achieve strong scalability. For me Java EE server are useless, you can get all feature from J2EE using a lightweight servlet container ... without the pain of managing a J2EE container. I must say that I don't do (and prefer to stay away from) Hibernate so my pov in biased ...

Nim Lhûg replied on Fri, 2010/06/11 - 11:59am

Ah. So many strong opinions. I'm sure you all realise that we're just talking about application servers here, right? Use whichever one suits your needs and quit dissing the ones that -- for whatever reason -- don't. They all have their merits and weaknesses. I have to say that I don't care about your (plural, author and moaning commenters) opinion any more than I care about your arseholes. I know you have one of each, but keep them to yourselves unless in a constructive context.


Kristian Rink replied on Sat, 2010/06/12 - 7:15am in response to: Nim Lhûg

Word. I agree. Problem however being things like this to go on forever, and personally, the same way I am annoyed by people goin' for FUD in terms of marketing, I am even more annoyed by those replying to FUD with other FUD. What the ...? At the very least, talking about "bloat", that's a word which, as a Java developer, am used to hear at least once per week talking to my fellows using Ruby(Rails) or Perl or something like that. It's just pointless. From a technical point of view I enjoy reading disputes regarding feature sets and the question which platform / environment / whatever suits best a given use case, but it should be somewhat neutral and unbiased - bashing people, projects, products doesn't get anyone anywhere...

Just my $0.02 / a**h**e, of course... ;)


Irek IrekM replied on Sat, 2010/06/12 - 12:40pm

Look at open-source web applications. Most popular of them (OSCommerce, WordPress, Joomla, Drupal, Wikipedia) were written in PHP.

I'm a Java developer and I'm not a PHP fan, but I think that Java EE application servers are too complex - in most cases a server like Tomcat is all we need!

Marc Stock replied on Sat, 2010/06/12 - 6:45pm

Kristian, way to step in for the corporate giants. Please explain to me where you think a J2EE server is appropriate. I've been at several places that use them and in each and every case I thought it was a complete waste of money and served nothing other than to lock the company into a particular vendor. It also appeared to me that whenever companies bought these servers that they often felt obligated to use EJBs (which have been disastrous since inception). I'm not saying they never have a purpose but they are FAR overused. Tomcat will work just fine in the vast majority of the cases and it doesn't cost a dime, and I've gotten better support from the Tomcat community (without any contracts mind you ) than I have from the likes of BEA when there's been problems found. Honestly I'm torn as to whether IE6 or expensive J2EE servers have wasted more money in production web development.

Kristian Rink replied on Sun, 2010/06/13 - 6:20am in response to: Marc Stock

I think there's a difference in between "Java EE" and "expensive Java EE servers". I also remember a time when people were mindlessly and head-first running to purchase WebSphere licenses (yes, it had to be the most expensive thing they could find these days) just to run applications for which a simple tomcat or another servlet container would have been totally sufficient. Then again: What's the point, at least from a cost-side point of view? Glassfish is free-of-charge and Java EE 6. Geronimo is free-of-charge and at least certified for Java EE 5. JOnAS is free-of-charge, not even company-backed, and at least Java EE 5 certified. JBoss is free-of-charge, also at the very least Java EE 5 certified, and at least same as widespread in use as tomcat. I really, honestly don't see how "tomcat-is-free-of-charge" is a good argument against Java EE.

 Really, I don't at all want to offend tomcat or tomcat users. But then again, what's the point in spending energy and development time, using something like Spring and a bunch of third-party dependencies in order to, after all, turn tomcat into something it never was intended to be - an application server virtually same as complex as a Java EE application server, yet way less maintainable and way less easier to explain to someone else because the amount of custom logic introduced eventually is way bigger? My opinion on that, here, is pretty simple:

- Use tomcat or jetty whenever Java EE web tier (Servlets, JSPs, ...) is all you need.

- Use an application server (be that Spring DM server or some Java EE server) whenever you need more, including multiple-tier applications, container managed persistence, transaction support and the like.

- Buy support for your server the way your business needs it. If this requires buying a license or not is something definitely not determined by technical reasons but in most cases, at least as I have seen so far, by political decisions ("we don't run open-source"). Glassfish or Geronimo communities, in example, are same as helpful as the (rather friendly indeed) tomcat folks - but altogether it won't help you much if you need a response immediately and timeframes are short. 

One final note: I always will remember the SOAP vs. CORBA dispute when SOAP came up. I will always remember how, these days, SOAP advocates were bashing at CORBA for being "complex, over-specified and bloated". A few years later, I see that as soon as you want to use SOAP on a functionality, performance and security level on par with CORBA, it also is _not simple_ anymore. As soon as you start messing with WS-* in example, SOAP also stops being fun, and you suddenly are to face the fact that complex problems (in case of CORBA: secure and reliable distributed communication at a decent performance level) will dictate a certain complexity to the solution as well. In terms of Java EE vs. tomcat, I see the same problem: Whenever you start doing anything more than writing simple, straightforward web applications, you will have to deal with application architecture and structuring. Java EE contains a whole load of support for this, as the overall architecture of Java EE has made up by specification commitees formed by people who rather well know these issues in theory and everyday work. So why to bash these technologies and re-invent the wheel rather than adopting them and see how far they get one? 


Ryan Developer replied on Sun, 2010/06/13 - 11:49am in response to: Irek IrekM

> I'm a Java developer and I'm not a PHP fan, but I think that Java EE application servers are too complex - in most cases a server like Tomcat is all we need!

So tell me Irek, how many frameworks and libraries does your Tomcat application use?  How many of those frameworks and libraries have equivalent Java EE standard APIs?   How many of those frameworks and libraries offer developers the choice between using proprietary APIs or Java EE APIs?  For example, Hibernate offers JPA 2.0 APIs, and CXF offers JAX-WS and JAX-RS APIs.   I think you will find that all you are doing is re-creating a home brew Java EE application server, and maintaining the integrations & upgrades manually adding unecessary complexity to your project.




Arbi Sookazian replied on Mon, 2010/06/14 - 6:27pm

Java EE 6 platform provides a "pruned" web profile with the RI (Glassfish V3).  This is closer to a "lightweight" solution that everyone in the Java EE space seems to be looking for recently.

 I have been using JBoss since 3.2.x.  It's open source and free.  Same as Apache Tomcat.  Same servlet container plus an EJB container that provides added value services like dependency injection, security, transactions, pooling, threading, etc.  You also get a jmx-console to manage MBeans as well as a web console.  And Tomcat does abide by some of the same JSRs that Java EE servers implement (e.g. Servlet 3.0 for Tomcat 7).

 In many cases, projects that don't use EJB select Tomcat, but I'm not sure there is really any significant advantage in choosing Tomcat over JBoss AS 5, for example.  They're both free, open source, production quality and cluster-ready servers (one for WARs and the other for WARs and EARs).

 I didn't know Mule ESB was a bad product, it's supposed to be very popular...

Kristian Rink replied on Tue, 2010/06/15 - 1:23am

I like tomcat (which we are excessively using in situations in which we just need a straightforward container in which to provide remote - SOAP, HTTP/REST, ... - access to some proprietary application/data store or in which servlet/JSPs simply suffice), and I also enjoyed working with Mule ESB back then when I was writing my diploma thesis. I also whole-heartedly understand the notion of "addressing FUD" related to Java EE servers, as these days (well, the last couple of years), the "lightweight-vs.-heavyweight" fight seems to have grown to the dimension of a religious war. Generally, my point of view here is rather pragmatic. Make up your requirements, go for a solution, and then see what suits things better both technically and from a support / licensing point of view. From that point of view, considering Java EE to be "bloated" in my opinion simply is nonsense, having not even slightly outlined what requirements should be met. We have non-trivial applications including Spring, built by maven2, being .war artifacts of about 20 megs in size, including Spring and hibernate and a whole load of other things that come as dependencies and transitive dependencies. Generally, I don't have a problem with the size (what's 20 megabytes, these days), and I don't really care about maven2 downloading them, but then again: Using Java EE technology that comes with glassfish, I can do the same thing with a jar or war file of < 2 megabytes, without even having to think or worry about resolving external dependencies as anything I have already is there in my development platform. "Bloat" isn't a very unbiased term...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.