Jakarta servlets & Spring Boot

Java EE vs Jakarta EE

We know that there is Java SE (Standard Edition) and Java EE (Enterprise Edition).

Additional packaged in Java EE used to be named javax.*, but after some point in time there were renamed to jakarta.*.

Now that thing is called Jakarta EE.

Jakarta Servlets

An important part of Jakarta is Servlets. They’re Java classes that process HTTP requests and generate responses.

Let’s say they’re “native-Java” controllers, like in Spring MVC.

Servlets are live in containers that manage them. It’s named as Jakarta Servlet Container or Jakarta Web Container.

Jakarta Servlet Containers

We create our own Servlet and register it in the Jakarta Servlet Container through the ServletContext class, calling addServlet() method.

Few examples of standalone Jakarta Servlet Containers are: Apache Tomcat and Eclipse Jetty.

We pack our app with Servlets (and their registrations) into .war file and deploy to the container.

Jakarta Application Servers

Jakarta EE is more than just Servlets. It also has a number of other features.

Jakarta Servlet Containers manage Servlets only. But Jakarta Application Servers support all (or almost all) Jakarta features like EJB, JPA, JMS, CDI, JTA, JAX-RS, etc.

Some Jakarta Application Servers are: Red Hat WildFly, Oracle WebLogic, Eclipse GlassFish.

If we need just to manage Servlets, we can use any of them.

Embedded Servlet Containers

We already spoke that there are standalone Servlet Containers: they work as self-contained apps where we deploy our .war app.

However, they are also embedded Servlet Containers. We can embed them directly to our application, and distribute that thing as .jar file.

Core process stays the same – we create Servlets and register them in ServletContext.

Apache Tomcat and Eclipse Jetty have their embedded versions.

Spring Boot Web apps

Spring Boot HTTP/REST capabilities it nothing more but Jakarta Servlet technology under the hood.

Just to be precise, we should mention that there are two types of Spring Boot apps:

• Spring Boot Web apps
• Spring Boot non-Web apps

Speaking about Spring Boot Web apps, where we can have REST controllers: it embeds Jakarta Servlet Container (Tomcat).

Spring has its own internal Servlet named DispatcherSevlet. Spring registers it automatically in ServletContext.

DispatcherSevlet has all necessary mappings for our Spring-based HTTP/REST controllers.

Therefore, the hierarchy is as following:

Standalone Java Application (Spring Boot Web app)
   ↳ Embedded Servlet Container (e.g., Tomcat)
       ↳ Jakarta ServletContext
           ↳ Spring's DispatcherServlet
               ↳ Controllers / @RequestMapping handlers

Spring Boot MVC

In this bonus section, let’s mention that Spring MVC app (HTTP/REST controllers) can exist in different formats.

First option: Spring Boot + Spring MVC

• Most common and “standard” approach
• Such apps can be distributed as regular .jar files.

Second option: Spring MVC + standalone Servlet Container

• No Spring Boot
• Standalone Servlet Container
• They should be deployed as .war files to standalone Jakarta Servlet Container or Jakarta Application Server.
• We should register Spring’s DispatcherSevlet in ServletContext manually.

Third option: Spring MVC + embedded Servlet Container

• We embed Servlet Container into our app manually
• We should register Spring’s DispatcherSevlet in ServletContext manually
• Such apps can be distributed as regular .jar files.

ServletContext and ApplicationContext

Don’t confuse Servlet Container (ServletContext) with Spring IoC container (ApplicationContext).

The ServletContext is provided by the Servlet Container and manages web components like Servlets and Filters.

The Spring ApplicationContext is a Spring-specific container that manages beans and dependency injection.

Spring’s DispatcherServlet acts as a bridge between the ServletContext and the Spring ApplicationContext, routing HTTP requests to Spring-managed controllers.