First of all the wording “JBoss” is improper. There is not anymore a single product called “JBoss”, but just a unit of Red Hat with that name which develops middleware products. (Check this to learn more: What is JBoss ?) I assume you are referring to “WildFly” application server that is the new name for the Community version of the application server developed by Red Hat Team.
WildFly vs Tomcat: the basics
The difference between WildFly and Tomcat is pretty straightforward: WildFly is a full Jakarta EE application Server, while Tomcat is a Java servlet container and web server and, since because it doesn’t come with an implementation of the full Jakarta EE stack, it is lighter out of the box. So in a nutshell, if you are designing a Java EE application that uses Servlets/JSP stuff you can run it both on WildFly and Tomcat. If you are using additional Jakarta EE components like EJB, CDI, Transaction Manager etc. then you need an application server like WildFly.
WildFly vs Tomcat: a modern view
Cleared the basics, today when we compare WildFly with Tomcat we often mean to compare Jakarta EE with Spring. Why ? in today’s projects, almost none (except very small projects) rely just on JSP or Servlets. Even if you just need the Web stack, a framework is needed on the top of it to organize most common aspects like Models, Controllers and Views. So we have to add something on the top of Tomcat to be more productive, resilient, reliable etc.
The natural choice if you don’t embrace the Jakarta EE standard is to use Spring, or the configuration-less version of it Spring Boot.
The comparison between Spring/Spring Boot and Java EE application servers like WildFly is often based on assumptions that just don’t fit it in any more. For example, the most common myth is that Java EE application servers are heavyweight and Spring is a lighter platform.
That just doesn’t make sense any more: as a matter of fact today application servers are also extremely fast and light. They switched from those monolythic architectures to very light, modular arhitectures. For example Wildfly features several profiles, each one using a different set of subsystems and modules: there is a default profile for non-clustered an non-JMS applications, one “full” profile which includes also JMS and Corba, an “HA” profile that adds clustering on the top of the “default” and a “full-ha” that delivers the full Java EE stack in clustered mode. In the recent version of the application server also a “load balancer” profile has been added so that WildFly can also be used as a front-end load balancer (similar to an Apache Web Server) to a back-end cluster. If that is not enough, you can still trim the application server, choosing which modules you want to use and which not, provided that you respect the dependencies of each module.
The real comparison between WildFly and Spring is done on other aspects.
Jakarta EE application servers are an effort for standardization. It takes what is done, or doable by most java enterprise software providers and sticks it into a document. This allows for a very nice portability situation, but in order to do that, it still must rely on the common denominator.
Spring, on the other hand, doesn’t have to do that. It is free to innovate, extend, that’s why you have so extremely nice Spring additions for some Big Data solutions, Spring Security and a lot of auto-configuration which enable developers to create projects more rapidly.
There’s a very good way of doing microservices in Spring boot although there are now also alternative solutions also in the Jakarta world, like for example the Runnable JAR project that lets you assemble a Jakarta EE application in an executable archive. Spring Boot has already started this race well ahead but if you have invested in learning or hiring Jakarta EE developers there is also the opportunity to develop micro services using the Jakarta EE stack.
You can read more about the Runnable JAR here: Turn your WildFly application in a Bootable JAR
WildFly vs Tomcat: the Apache Tom EE project
Spring is not the only alternative to expand the default Tomcat installation. Another option is using Apache TomEE which is a Java EE Web Profile-certified stack which is built on top of an Apache Tomcat base integrated with additional related technologies. It adds implementations for the following specifications (using the Apache project shown in parentheses):
- CDI – Apache OpenWebBeans
- EJB – Apache OpenEJB
- JPA – Apache OpenJPA
- JSF – Apache MyFaces
- JSP – Apache Tomcat
- JSTL – Apache Tomcat
- JTA – Apache Geronimo Transaction
- Servlet – Apache Tomcat
- Javamail – Apache Geronimo JavaMail
- Bean Validation – Apache BVal
- JAX-RS – Apache CXF
- JAX-WS – Apache CXF
- JMS – Apache ActiveMQ
- Connector – Apache Geronimo Connector
Conclusion
To sum up from the original question “JBoss vs Tomcat” or better to say “WildFly vs Tomcat” it boils down mostly to a Spring vs Java EE
Java EE Pros:
1. Relies on standard specifications which guarantees stability in your projects.
2. Has a robust set of management interface to admin the application server
3. Is a robust solution which provides out of the box load balancing and high availability
Spring/Spring Boot Pros:
1. Provides since the beginning innovative concepts like Inversion Of Control / Dependency Injection and (Spring Boot) auto-configuration with sensible defaults
2. Provides a powerful CLI to bootstrap projects
3. Provides (Spring Boot) an already well popular solution for developing microservices
You can get learning more about Spring Boot in our new site that contains lots of Spring Boot tutorials.
Found the article helpful? if so please follow us on Socials
