May 17, 2012 by

Tomcat has been a very popular alternative to other application servers like JBoss, WebLogic and WebSphere. People preferred it for its simplicity. I am writing this article to point out how Java EE 6 changes things and why using tomcat could be downright harmful.

Let’s have a quick summary of what makes Java EE 6 so great:

  • Contexts and Dependency Injection (CDI).
  • Java Server Faces (JSF) 2.0.
  • No interface EJB and ability to create EJB in a web module.
  • RESTful Web Service using JAX-RS.

There is the problem with Tomcat right there. None of the above technologies are supported by Tomcat out of the box. Surely, you can add enough JAR files to your web project to get CDI, JSF and JAX-RS. After you are done doing that, you have pretty much created a JBoss look alike. Even then, CDI will be semi-functional. CDI really needs a proper Java EE web and EJB container.

Finally, lack of EJB remains a huge elephant in the room. Sure, EJB was complicated and over engineered. There were good reasons to shun it. That’s not the case any more. EJB has been simplified to the extent it is downright criminal not to use session EJB as your façade to the model layer.

EJB buys you several valuable architecture attributes:

  • You get automated transaction management.
  • You get role based security.
  • Doing audit logging from the model layer becomes a breeze (since you know the user Principal).
  • @Startup and @Singleton classes for better application initialization.
  • Stateless session EJBs can be directly exposed as RESTful Web Services, there by creating a fully transactional and secure interface. With JAX-RS, you can secure a POJOs resource but don’t get transaction support.

All it takes is one extra line to create an EJB:

@Stateless //No interface local EJB
public class OrderManager {


You can even create these EJBs right within your web module. There is no excuse not to use them.

Edited: Apache TomEE project has assembled these missing pieces and integrated them with Tomcat. This is the correct direction for the Tomcat project. My problem with Tomcat is that most shops that will use it will shy away from what is so great about Java EE 6. Don’t do that to yourself. Switch to JBoss, Glassfish or TomEE.


Bibhas Bhattacharya

Thanks for the comment. Very appropriate for this post. What distinguishes TomEE is that all components are from Apache group. Other than that, very little makes it stand apart from Glassfish or JBoss. I wish them good luck though and I will keep an eye out for them.

Also, I don’t understand why some keep saying that Java EE is complicated and then go ahead and pile on MyFaces, JAX-RS, JAX-WS, JPA and all that on top of Tomcat.

David Blevins

Great blog post! You nailed the motivation for creating TomEE.

After 10 years people are still fighting using a compliant Java EE server even though there are great options. Often this is even used as a reason to hate Java EE even though people are clearly building their own Java EE server.

With TomEE we wanted to show that, yes, that is Java EE and, yes, it can be certified. People can continue to build their own DIY uncertified JavaEE servers on Tomcat, but with the existence of TomEE it doesn’t make much sense.

Very relavent StackOverflow answer to the question, “Besides EAR and EJB, what do I get from a J2EE app server that I don’t get in a servlet container like Tomcat?”

This is basically part 2 of your great blog post. Keep fighting the good fight!

Bibhas Bhattacharya

David, it’s good to have you here commenting on my blog. You have taken it upon yourself a worthy cause. Without an unifying system like TomEE, projects like Tomcat, OpenJPA, CXF and so on will be in danger of irrelevance. Savvy users will begin switching to Glassfish or JBoss. Developers of these projects need to realize that CDI, EJB3.1, JPA, JAX-RS etc. are not luxuries any more, they are (or should be) the essential part of a modern architecture.

Good luck with your effort.


Why use EJB? Spring Tomcat can meet all enterprise level requirements. JEE takes hell lot of time to evolve and even when it evolves, companies try to push their agenda. Spring community is far more agile.

Bibhas Bhattacharya

Hi Shailendra, Spring vs. Java EE is a different discussion. To get to the core of your comment, Tomcat is not a transaction coordinator and can not support XA transaction. That right there fails it for enterprises. Enterprises also need messaging heavily, not to mention good Web Service support (WS-RM, WS-Notification, WS-Security etc.). Tomcat is not even close to meeting these needs, with Spring or otherwise. Spring is a wrapper of underlying services. It can only do so much when the underlying infrastructure is totally inadequate.

Gabriel Axel

I beg to differ about your approach. Picking a technology stack before carefully examining your needs is a very bad idea in my opinion. A very good rule of thumb I have adopted is to pick the simplest solution as possible, and in many cases I’ve seen people go for JEE where much simpler solutions exist for the project. If you actually need a significant part of JEE features – sure go for it, but don’t take it as a default stack for every Java project.
A significant drawback of choosing JEE is that you may be stuck with existing APIs for a very long time, while third party libraries (eg: Spring, Guice, Hibernate, etc’) are evolving much faster, so at any given time JEE can only be as good as such libraries, certainly not ahead of them, and usually far behind them.

Bibhas Bhattacharya

I agree in principle that if innovation is happening faster outside of Java EE, one should look to tap it.


>Why use EJB?

Because it’s a simpler model than Spring, yet more powerful. As an added bonus, it already comes with most application servers. Tomcat is one of the very few that doesn’t include EJB.


Today JBoss7, Glassfish and TomEE are lightning fast! I understand your point. I prefer full-EE too.

I use Seam because it brings me the freedom of choose. With Seam you have both options: simple war or a full-ee ear. Your choose.

Not every app has the same needs. “One size feets alls” is a fake.

But, you can get (almost) all of that with Seam over Tomcat too. So, YMMV.


Here you ask the wrong question: “why use tomcat when you want in fact a JEE server?”

Obviously, if you want a JEE server, you get one, maybe one that include tomcat as part of it, but that ok.

But using a JEE stack is thinking that:
1) either the JEE stack is the only true perfect one that you should choose for most apps. Others are worse.
2) either that any stack is equivalent, so it doesn’t matter (so you could choose another one too; it doesn’t matter).
3) either you admit that you need the best tool for the job and it just happen your project benefit most of JEE.

Most JEE supporters argument are mainly on 1) and 2). They implicitely value most architecture has equivalent or worse to last JEE and because I suppose they prefer Oracle to SpringSource, MS or IBM, they choose JEE.

I really doubt that one architecture can fit all needs. You see I’am more on the 3) case. Yes Oracle (well in reality Sun) did a great job. No doubt about that. But its solution is for a specific case. I would say internal IT with web frontend using “rich components” and heavy state on the server (both from statefull EJB and JSF). This architecture tend to fade and start to show its limits. And in all cases it is somewhat expensive to operate on a high volume website.

There no point to use it by default.


I think there are probably three audiences out there using Tomcat:

1 – Using it for Servlet/JSP (maybe Struts) and NOTHING ELSE
2 – Using it with several additions like ActiveMQ or JSF implementation to add needed function
3 – Using it with Spring and several of the same libraries from #2

For those in group #1 there is no need to move to a Java EE server and those saying it is overkill are correct.

For those in group #2 the point is why spend your time adding functionality to a Tomcat server when there is TomEE and other Java EE servers out there? I think that was the main point of the article.

For those in group #3 I think it is a little trickier since we are now comparing Tomcat Spring with Java EE 6. I am a big fan of Spring but one thing I find is that a lot of the reasons that people originally moved to Spring are not true for Java EE 6 anymore (EJBs are difficult to program, Java EE servers are huge, slow monoliths, etc). In fact, you could even make some of the same arguments for moving AWAY from Spring and BACK to Java EE 6 because in many cases the programming in Java EE 6 is slightly simpler than Spring (not even minimal Spring XML configuration or Spring JARs).

One thing that I think is true is that the last two versions of Java EE (5 & 6) have seen a rapid acceleration in bringing innovation from the Java community (including Spring) back into the Java EE standards. I think what we should be looking to do now is use Java EE as much as possible and use the extensions like Spring/Seam where they provide extensions and utility libraries to simplify coding where possible.

Bibhas Bhattacharya

Hi Stuart, yes, yours is a more well rounded reasoning of the situation. My article is more narrowly focused on item #2. In addition, to be honest, I did implicitly address item #3 by suggesting the use of CDI/EJB etc. instead of Spring. My opinion was stated rather indirectly (but not lost on most readers) because I am still open to more discussion on how Java EE 6 impacts the decision to use Spring in a new project.

I look at what most modern applications need – rich web interface, REST API, persistence and rapid development. Then I look at what Java EE 6 brings to the table. I must say, it makes a compelling case. It’s main challenge is to make up for past sins. Like many readers here, many have made up their mind about Java EE and not likely to change soon.

Stuart McIntyre

> why using tomcat could be downright harmful.
>You can even create these EJBs right within your web module. There is no excuse not to use them.

Really disagree with the tone of your post.

>Finally, lack of EJB remains a huge elephant in the room
>Apache TomEE project has assembled these missing pieces and integrated them with Tomcat. This is the correct direction for the Tomcat project.

You can’t make decisions like this without knowing the problem you’re trying to solve. It’s ridiculous to say that xyz is the “correct direction”. Many large Java applications work great on Tomcat with Spring. No need for EJB at all. Spring offers all the features you have mentioned regarding EJB.

Bibhas Bhattacharya

I do not doubt that many large applications have worked fine with Tomcat. The point of this article is regarding the architecture for future applications. There are two parts to it – (a) Spring vs. CDI (b) Frameworks like JSF, JAX-RS and JAX-WS. Even if we defer a discussion on CDI for another day, option (b) is compelling for most modern software. My recommendations are not meant for 100% of all applications but for majority of server side applications written in Java.

Pucer Puce

Tomcat should still be the goto choice instead of Java EE. Tomcat has superior graphics and font handling and doesn’t corrupt the Windows registry with the toolbars.


You make a lot of assumptions about any given developers problem domain. Tomcat does not support EJB because it was designed to be a servlet/jsp container and not an application container. It’s also lightweight and easy to manage and maintain and startup and shutdowns are lighting fast. JEE was intentionally split into multiple modules so that you could plug and play as you required a specific technology. Apache could have just added the jars and libs for all the technologies you mention it’s hardly difficult, but they chose not to and leave it up to you what you want to add or not add.
If your problem domain requires a certain amount of features that application containers provide sure their a great choice, but if your problem domain is relatively simple (lets say a timesheet tracking system or such) I reckon your better of with a servlet container like tomcat.

David Blevins

Dee :
Apache could have just added the jars and libs for all the technologies you mention it’s hardly difficult, but they chose not to and leave it up to you what you want to add or not add.

Small correction, Apache did decide to put those jars into Tomcat — that’s what TomEE is. It was very hard.

After we dropped the jars into Tomcat, it took us another year of integration and testing before we could complete the Web Profile.

Miten Mehta


I think spring does not provide the instance pooling like for stateless session bean in ejb server. could it be issue in scalability ?

Stuart Smith

The default in Spring is to have every bean be a singleton. There is a ‘prototype’ scope that can be used but this will create a new instance every time and probably not be the best for scalability either.
With Spring, it is possible to have Spring use a pool of instances using Jakarta Commons Pool library. The Spring documentation for how to do this is here:
Now if you are trying to figure out which is “easier”, certainly it is more work to do this with Spring while with EJB it is just built-in. There are becoming more and more cases where doing something with Java EE is easier than doing it with Spring but Spring still provides a lot of utility libraries which are useful.

Comments are closed.