Spring boot 3 что нового

Spring Boot 3.0 — готовимся заранее

Здравствуй, читатель Хабра!
До выхода Spring Boot 3 осталось совсем немного — 3 месяца. Уже появляются статьи —
What’s New, It’s time to get ready. Недавно JetBrains выпустила IDEA с поддержка Spring 6 и Spring Boot 3. Самое время потренироваться заранее в миграции. В разработке нового учебного курса я попробовал перевести свой открытый учебный проект Spring Boot 2.x + HATEOAS на Spring Boot 3, шаги и код проекта ниже.

За основу взят код открытого проекта Spring Boot 2.x + HATEOAS (код на GitHub в ветке patched). Функционал простой — основа любого современного REST веб-приложения: аутентификация и авторизация на основе ролей, регистрация пользователя в приложении, управление своим профилем и администрирование пользователей.

Первым комитом (ветка patched) перевел проект с Maven на Gradle — давно хотел, появился повод:) Примечание — против Maven ничего не имею, для сравнения Gradle и Maven есть отдельные статьи и дискуссии.

Далее будет разбор второго шага — кода миграции: сommit details
Для разбора проще всего вычекать к себе проект с этой ревизией:

git clone —branch patched https://github.com/JavaOPs/cloudjava
cd cloudjava
git checkout 2d74f6158b8380587a3360e911e3a6ff42c49642

• Обновляем версию Spring и добавляем snapshot репозитории в build.gradle
• Меняем зависимость springdoc-openapi на springdoc-openapi-starter-webmvc-ui и пакет для GroupedOpenApi : смотри SpringDoc OpenAPI 2.x migration guide
• Добавляем snapshot репозитории в settings.gradle
• В коде всего проекта меняем javax.validation и javax.servlet на jakarta (можно контекстной заменой). Здравствуй JPA 3, Hibernate 6, Hibernate Validator 7 и Tomcat 10 !
• Обновляем зависимость jackson-datatype-hibernate5 на jackson-datatype-hibernate5-jakarta . В AppConfig также делаем замену Hibernate5Module на Hibernate5JakartaModule
• В GlobalExceptionHandler меняем HttpStatus на HttpStatusCode . Появилась новая иерархия статусов возврата без требования быть enum . Однако для getReasonPhrase() теперь приходится делать instanceof HttpStatus
• В AdminUserControllerTest не идут тесты на запросы со слешем в конце. Сделал отдельную переменную REST_URL_SLASH

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

И — желаю успехов с обновлением на Spring Boot 3!

Spring Boot 3.0 — готовимся заранее

До выхода Spring Boot 3 осталось совсем немного — 3 месяца. Уже появляются статьи —
What’s New, It’s time to get ready. Недавно JetBrains выпустила IDEA с поддержка Spring 6 и Spring Boot 3. Самое время потренироваться заранее в миграции. В разработке нового учебного курса я попробовал перевести свой открытый учебный проект Spring Boot 2.x + HATEOAS на Spring Boot 3, шаги и код проекта ниже.

За основу взят код открытого проекта Spring Boot 2.x + HATEOAS (код на GitHub в ветке patched). Функционал простой — основа любого современного REST веб-приложения: аутентификация и авторизация на основе ролей, регистрация пользователя в приложении, управление своим профилем и администрирование пользователей.

Первым комитом (ветка patched) перевел проект с Maven на Gradle — давно хотел, появился повод:) Примечание — против Maven ничего не имею, для сравнения Gradle и Maven есть отдельные статьи и дискуссии.

Далее будет разбор второго шага — кода миграции: сommit details
Для разбора проще всего вычекать к себе проект с этой ревизией:

git clone —branch patched https://github.com/JavaOPs/cloudjava
cd cloudjava
git checkout 2d74f6158b8380587a3360e911e3a6ff42c49642

• Обновляем версию Spring и добавляем snapshot репозитории в build.gradle
• Меняем зависимость springdoc-openapi на springdoc-openapi-starter-webmvc-ui и пакет для GroupedOpenApi : смотри SpringDoc OpenAPI 2.x migration guide
• Добавляем snapshot репозитории в settings.gradle
• В коде всего проекта меняем javax.validation и javax.servlet на jakarta (можно контекстной заменой). Здравствуй JPA 3, Hibernate 6, Hibernate Validator 7 и Tomcat 10 !
• Обновляем зависимость jackson-datatype-hibernate5 на jackson-datatype-hibernate5-jakarta . В AppConfig также делаем замену Hibernate5Module на Hibernate5JakartaModule
• В GlobalExceptionHandler меняем HttpStatus на HttpStatusCode . Появилась новая иерархия статусов возврата без требования быть enum . Однако для getReasonPhrase() теперь приходится делать instanceof HttpStatus
• В AdminUserControllerTest не идут тесты на запросы со слешем в конце. Сделал отдельную переменную REST_URL_SLASH

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

И — желаю успехов с обновлением на Spring Boot 3!

Spring Boot 3.2.0 available now

On behalf of the Spring Boot team and everyone that has contributed, I am pleased to announce that Spring Boot 3.2.0 has been released and is available from Maven Central.

This release adds a significant number of new features and improvements. For full upgrade instructions and new and noteworthy features please see the release notes.

What’s new in 3.2

The highlights of the 3.2 release include:

• Support for Virtual Threads
• Initial support for JVM Checkpoint Restore (Project CRaC)
• SSL Bundle Reloading
• A lot of Observability Improvements
• Support for RestClient
• Support for JdbcClient
• Support for Jetty 12
• Support for Spring for Apache Pulsar
• SSL bundle support for Kafka and RabbitMQ
• Reworked Nested Jar handling
• Docker Image Building improvements

Spring Boot 3.2 moves to new versions of several Spring projects and we’ve also upgraded to the latest stable releases of other third-party libraries wherever possible. Please see the release notes for details.

There are many other changes and improvements that are documented in the release notes. You can also find a list of deprecated classes and methods that we plan to remove in the future.

We want to take this opportunity to again thank all our users and contributors.

If you’re interested in helping out, check out the «ideal for contribution» tag in the issue repository. If you have general questions, please ask at stackoverflow.com using the spring-boot tag or chat with the community on Gitter.

Get the Spring newsletter

Thank you for your interest. Someone will get back to you shortly.

Get ahead

VMware offers training and certification to turbo-charge your progress.

Get support

Tanzu Spring Runtime offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Upcoming events

Check out all the upcoming events in the Spring community.

Copyright © 2005 — 2024 Broadcom. All Rights Reserved. The term «Broadcom» refers to Broadcom Inc. and/or its subsidiaries.
Terms of Use • Privacy • Trademark Guidelines • Your California Privacy Rights • Cookie Settings

Apache®, Apache Tomcat®, Apache Kafka®, Apache Cassandra™, and Apache Geode™ are trademarks or registered trademarks of the Apache Software Foundation in the United States and/or other countries. Java™, Java™ SE, Java™ EE, and OpenJDK™ are trademarks of Oracle and/or its affiliates. Kubernetes® is a registered trademark of the Linux Foundation in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Windows® and Microsoft® Azure are registered trademarks of Microsoft Corporation. “AWS” and “Amazon Web Services” are trademarks or registered trademarks of Amazon.com Inc. or its affiliates. All other trademarks and copyrights are property of their respective owners and are only mentioned for informative purposes. Other names may be trademarks of their respective owners.

Docker Compose и Testcontainers в Spring Boot 3.1

Одними из наиболее значимых нововведений в недавнем релизе Spring Boot 3.1 на мой взгляд являются поддержка Docker Compose и Testcontainers, а так же новая концепция подключений к сервисам, которая позволяет с минимальным количеством кода подключаться к сервисам, развёрнутым в контейнерах.

Подключения к сервисам

В Spring Boot до версии 3.1 настройки подключений к сервисам описывались классами, отмеченными аннотациями @ConfigurationProperties , значения свойств которых загружались из файлов свойств.

Теперь же для указания основных настроек подключений к сервисам, хоть и не всем, используются классы, реализующие интерфейс ConnectionDetails и его наследников ( JdbcConnectionDetails , MongoConnectionDetails и т.д.). Так, например, для указания настроек подключения к реляционным базам данных теперь используются реализации интерфейса JdbcConnectionDetails .

Если же в контексте приложения нет зарегистрированных компонентов ConnectionDetails с настройками подключения к какому-нибудь сервису, то Spring Boot попытается создать соответствующий компонент на основе значений из файлов свойств, как это было и раньше. Например, если в контексте приложения отсутствует компонент с настройками подключения к реляционной базе данных, Spring Boot попытается зарегистрировать компонент PropertiesJdbcConnectionDetails . То есть с точки зрения разработчика приложения на Spring Boot кардинально ничего не изменилось.

Стоит отметить, что ConnectionDetails содержит только основные параметры для подключения к сервисам: ip-адрес, имя хоста, порт, имя пользователя, пароль и т.д. Различные специфичные или не столь важные параметры, например параметры источника данных HikariCP, будут по-прежнему браться из файлов свойств.

Так же нужно упомянуть факт того, что список поддерживаемых сервисов сейчас невелик, но он, скорее всего, будет увеличиваться. В настоящее время этот список выглядит следующим образом:

• Apache Cassandra
• Couchbase
• Elasticsearch
• Flyway
• JDBC-совместимые СУБД
• Apache Kafka
• Liquibase
• MongoDB
• Neo4j
• R2DBC-совместимые СУБД
• RabbitMQ
• Redis
• Zipkin

Интеграция с Docker Compose

Теперь Spring Boot может при запуске приложения автоматически запускать необходимые контейнеры, описанные в файле Docker Compose.

Чтобы использовать интеграцию с Docker Compose потребуется зависимость spring-boot-docker-compose :

Если вы хотите использовать интеграцию с Docker Compose не только в процессе разработки, но и в процессе реальной эксплуатации сервиса, то необходимо выключить исключение этого модуля при сборке проекта в настройках плагина Spring Boot:

Настраивать интеграцию с Docker Compose можно следующими свойствами:

Кроме того, Spring Boot может автоматически сконфигурировать подключения к некоторым сервисам на основе данных, полученных от запущенных контейнеров, благодаря реализации новой концепции подключений к сервисам.

Файлы Docker Compose

По умолчанию Spring Boot ищет в директории приложения следующие файлы:

• compose.yml
• compose.yaml
• docker-compose.yml
• docker-compose.yaml

Впрочем, вы можете самостоятельно указать используемый файл при помощи свойства spring.docker.compose.file , указанного выше.

Управление жизненным циклом

Настраивать управление жизненным циклом контейнеров можно при помощи свойства spring.docker.compose.lifecycle-management , которое может иметь следующие значения:

• start_and_stop — запуск контейнеров при запуске приложения и остановка — при остановке приложения, по умолчанию
• start_only — запуск контейнеров при запуске приложения, контейнеры продолжат работать после остановки приложения
• none — не использовать управление жизненным циклом контейнеров, этот вариант предполагает ручное управление Docker Compose

Так же можно настраивать процесс запуска и остановки контейнеров. При помощи свойства spring.docker.compose.start.command можно задать команду, при помощи которой будут запускаться контейнеры, это может быть start или up (по умолчанию). При помощи свойства spring.docker.compose.stop.command можно указать команду для остановки контейнеров: down или stop (по умолчанию). Так же можно указать время ожидания запуска и остановки контейнеров при помощи свойств spring.docker.compose.start.timeout и spring.docker.compose.stop.timeout соответственно.

Ожидание доступности контейнеров

На запуск контейнера в Docker может потребоваться какое-то время. И чтобы при запуске разрабатываемого приложения не возникло ошибок нужно дождаться готовности запускаемых контейнеров.

Параметры проверок доступности сервисов обычно задаются в свойстве healthchecks контейнера в compose.yaml. Кроме этого Spring Boot может проверять доступность сервиса напрямую, обращаясь к нему по TCP. По умолчанию контейнер считается доступным, когда TCP/IP-соединение на целевой порт может быть установлено. Это поведение можно отключить для контейнера при помощи метки org.springframework.boot.readiness-check.tcp.disable: true :

Так же при помощи свойств Spring Boot, описанных выше, можно задавать свои таймауты проверок доступности:

При помощи параметра spring.docker.compose.readiness.wait можно указывать вариант ожидания доступности контейнера:

• always — всегда ожидать доступности, по умолчанию
• never — никогда не ожидать доступности
• only_if_started — ожидать, если жизненным циклом контейнера управляет Spring Boot

Собственные образы поддерживаемых сервисов

Подключение к сервису, развёрнутому в контейнере, будет автоматически сконфигурировано только в том случае, если контейнер использует оригинальный образ сервиса из списка, указанного выше. Если вы используете ваш собственный образ, основанный на оригинальном, то вы можете подсказать Spring Boot, как настраивать подключение при помощи метки org.springframework.boot.service-connection . Например, в одном из моих проектов используется модифицированный образ СУБД PostgreSQL, и чтобы Spring Boot смог работать с этим образом, как с оригинальным, достаточно сделать следующее:

Список всех поддерживаемых значений метки org.springframework.boot.service-connection :

• cassandra
• elasticsearch
• mariadb
• mongo
• mysql
• gvenzl/oracle-xe
• rabbitmq
• redis
• mssql/server
• openzipkin/zipkin

Игнорирование подключений к сервисам

Если вы не хотите, чтобы Spring Boot автоматически создавал подключение к сервису, запущенному в контейнере, то вы можете для этого использовать метку org.springframework.boot.ignore: true :

Активация профилей Docker Compose

Для запуска разного набора контейнеров в Docker Compose в зависимости от окружения можно использовать профили. Список активных профилей Docker Compose можно задать в свойстве spring.docker.compose.profile.active :

Для запуска Docker Compose с профилем pg14 :

Интеграция с Testcontainers

Начиная с версии 3.1 Spring Boot BOM включает Testcontainers, версию которого при желании можно специфицировать при помощи свойства testcontainers.version .

Для использования Testcontainers в тестах со Spring Boot потребуются как минимум следующие зависимости:

Теперь можно создавать контейнеры в тестах:

Аннотация @Testcontainers добавляет расширение Testcontainers для JUnit, которое автоматически запускает и останавливает контейнеры в тестах.

При помощи аннотации @Container вы можете отметить свойства, описывающие контейнеры, жизненным циклом которых должен управлять фреймворк Testcontainers.

Контейнер, описываемый статическим свойством тестового класса, будет запускаться один раз и использоваться при выполнении всех тестов в классе. Контейнер, описываемый свойством объекта, будет запускаться для каждого теста заново.

Подключения к сервисам

Контейнеры, управляемые Testcontainers, могут использоваться в качестве источников параметров для подключений к сервисам. Для этого вам потребуется зависимость spring-boot-testcontainers :

Теперь можно автоматически создать подключение к сервису, развёрнутому в контейнере при помощи аннотации @ServiceConnection :

Динамические источники свойств

Контейнеры, развёрнутые при помощи Testcontainers можно использовать в качестве динамических источников свойств. Для добавления свойств в тесте необходимо создать статический метод, отмеченный аннотацией @DynamicPropertySource и принимающий аргумент типа DynamicPropertyRegistry :

Использование Testcontainers для ручного тестирования

Иногда в процессе разработки возникают ситуации, когда нужно запустить сервис и вручную проверить работу ту или иной функции. Обычно для этого нужно развёртывать и настраивать какое-то окружение — те же базы данных.

Интеграция Spring Boot и Testcontainers позволяет упростить этот процесс, автоматизируя развёртывание требуемого окружения в контейнерах. В отличие от интеграции Spring Boot с Docker Compose Testcontainers по умолчанию удаляет контейнеры после остановки приложения.

Чтобы использовать Testcontainers для ручного тестирования, нужно создать стартовый класс в директории с исходными кодами тестов, а так же тестовый класс-конфигурацию:

Обратите внимание на аннотацию @TestConfiguration , класс отмеченные этой аннотацией не используются в качестве классов конфигурации автоматически — их нужно указывать вручную в нужных тестах.

Допустим, главный стартовый класс приложения — pro.akosarev.sandbox.SandboxApplication , тогда можно создать стартовый класс для тестирования pro.akosarev.sandbox.TestSandboxApplication со следующим методом main :

Теперь можно запустить приложение через main -метода класса TestSandboxApplication . В Maven это можно сделать при помощи команды mvn spring-boot:test-run .

Полезные ссылки

• Страница релиза Spring Boot 3.1
• Документация Spring Boot по интеграции с Docker Compose
• Документация Spring Boot по интеграции с Testcontainers

Понравилась статья? Тогда поддержки проект и подкинь монетку:

Больше полезных статей и роликов: