Сервлеты Jakarta и Spring Boot

Java EE vs Jakarta EE

Мы знаем, что есть Java SE (Standard Edition) и Java EE (Enterprise Edition).

Дополнительные пакеты в Java EE раньше назывались javax.*, но через некоторое время они были переименованы в jakarta.*.

Теперь это называется Jakarta EE.

Сервлеты Jakarta

Важной частью Jakarta являются сервлеты. Это классы Java, которые обрабатывают HTTP-запросы и генерируют ответы.

Скажем так, это “нативные Java” контроллеры, как в Spring MVC.

Сервлеты находятся в контейнерах, которые ими управляют. Это называется Jakarta Servlet Container или Jakarta Web Container.

Контейнеры сервлетов Jakarta

Мы создаем наш собственный сервлет и регистрируем его в контейнере сервлетов Jakarta через класс ServletContext, вызывая метод addServlet().

Несколько примеров standalone контейнеров сервлетов Jakarta: Apache Tomcat и Eclipse Jetty.

Мы упаковываем наше приложение с сервлетами (и их регистрациями) в файл .war и развертываем его в контейнере.

Серверы приложений Jakarta

Jakarta EE – это больше, чем просто сервлеты. Она также имеет ряд других возможностей.

Контейнеры сервлетов Jakarta управляют только сервлетами. Но Серверы приложений Jakarta поддерживают все (или почти все) возможности Jakarta, такие как EJB, JPA, JMS, CDI, JTA, JAX-RS и т.д.

Некоторые серверы приложений Jakarta: Red Hat WildFly, Oracle WebLogic, Eclipse GlassFish.

Если нам нужно только управлять сервлетами, мы можем использовать любой из них.

Встраиваемые контейнеры сервлетов

Мы уже говорили, что существуют standalone контейнеры сервлетов: они работают как самостоятельные приложения, куда мы развертываем наше приложение .war.

Однако существуют также встраиваемые контейнеры сервлетов. Мы можем встроить их непосредственно в наше приложение и распространять это как файл .jar.

Основной процесс остается тем же – мы создаем сервлеты и регистрируем их в ServletContext.

Apache Tomcat и Eclipse Jetty имеют свои встраиваемые версии.

Веб-приложения Spring Boot

Возможности HTTP/REST в Spring Boot работает на Jakarta сервлетах под капотом.

Нужно упомянуть, что существует два типа приложений Spring Boot:

• Веб-приложения Spring Boot
• Не веб-приложения Spring Boot

Веб-приложения Spring Boot, где можно создавать REST-контроллеры, имеют контейнер сервлетов Jakarta (Tomcat).

У Spring есть свой внутренний сервлет под названием DispatcherSevlet. Spring автоматически регистрирует его в ServletContext.

DispatcherSevlet содержит все необходимые маппинги для наших HTTP/REST Spring-based контроллеров.

Следовательно, иерархия следующая:

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

Spring Boot MVC

В этом бонусном разделе давайте упомянем, что приложение Spring MVC (HTTP/REST-контроллеры) может существовать в различных форматах.

Первый вариант: Spring Boot + Spring MVC

• Наиболее распространенный и “стандартный” подход
• Такие приложения могут распространяться как обычные файлы .jar.

Второй вариант: Spring MVC + standalone контейнер сервлетов

• Без Spring Boot
• Standalone контейнер сервлетов
• Их следует развертывать как файлы .war в standalone контейнер сервлетов Jakarta или Сервер приложений Jakarta.
• Мы должны вручную зарегистрировать DispatcherSevlet от Spring в ServletContext.

Третий вариант: Spring MVC + встраиваемый контейнер сервлетов

• Мы вручную встраиваем контейнер сервлетов в наше приложение
• Мы должны вручную зарегистрировать DispatcherSevlet от Spring в ServletContext
• Такие приложения могут распространяться как обычные файлы .jar.

ServletContext и ApplicationContext

Не стоит путать контейнер сервлетов (ServletContext) с IoC-контейнером Spring (ApplicationContext).

ServletContext предоставляется контейнером сервлетов и управляет веб-компонентами, такими как сервлеты и фильтры.

ApplicationContext от Spring – это специфичный для Spring контейнер, который управляет бинами и внедрением зависимостей.

DispatcherServlet от Spring действует как bridge между ServletContext и ApplicationContext от Spring, направляя HTTP-запросы к контроллерам, управляемым Spring.