Spec-Zone.ru › Spring Boot

Разработка с Spring Boot

В этом разделе подробно рассказывается о том, как использовать Spring Boot. Он охватывает такие темы, как системы сборки, автоматическую настройку и запуск приложений. Мы также рассмотрим некоторые лучшие практики Spring Boot. Хотя в Spring Boot нет ничего особенного (это просто еще одна библиотека, которую можно использовать), есть несколько рекомендаций, которые, если их соблюдать, упрощают процесс разработки.

Если вы только начинаете работу с Spring Boot, перед погружением в этот раздел, вам следует прочитать руководство Начало работы.

1. Системы сборки

Систему сборки рекомендуется выбирать с поддержкой управления зависимостями и способную потреблять артефакты, опубликованные в репозитории “Maven Central”. Рекомендуется использовать Maven или Gradle. Возможно заставить Spring Boot работать с другими системами сборки (например, Ant), но они не так хорошо поддерживаются.

1.1. Управление зависимостями

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

Вы все равно можете указать версию и переопределить рекомендации Spring Boot, если это необходимо.

Составленный список содержит все модули Spring, которые можно использовать с Spring Boot, а также уточненный список библиотек сторонних разработчиков. Список доступен в виде стандартного файла Bills of Materials (spring-boot-dependencies) и может использоваться как с Maven, так и с Gradle.

Каждый релиз Spring Boot связан с базовой версией Spring Framework. Мы настоятельно рекомендуем не указывать его версию.

1.2. Maven

Чтобы узнать о использовании Spring Boot с Maven, ознакомьтесь с документацией плагина Maven для Spring Boot:

  • Справочник (HTML и PDF)

  • API

1.3. Gradle

Чтобы узнать о использовании Spring Boot с Gradle, ознакомьтесь с документацией плагина Gradle для Spring Boot:

  • Справочник (HTML и PDF)

  • API

1.4. Ant

Возможно создание проекта Spring Boot с использованием Apache Ant+Ivy. Также доступен модуль spring-boot-antlib “AntLib” для помощи Ant в создании исполняемых JAR-файлов.

Для объявления зависимостей типичный ivy.xml файл выглядит примерно так:

<ivy-module version="2.0">
    <info organisation="org.springframework.boot" module="spring-boot-sample-ant" />
    <configurations>
        <conf name="compile" description="everything needed to compile this module" />
        <conf name="runtime" extends="compile" description="everything needed to run this module" />
    </configurations>
    <dependencies>
        <dependency org="org.springframework.boot" name="spring-boot-starter"
            rev="${spring-boot.version}" conf="compile" />
    </dependencies>
</ivy-module>

Типичный build.xml файл выглядит примерно так:

<project
    xmlns:ivy="antlib:org.apache.ivy.ant"
    xmlns:spring-boot="antlib:org.springframework.boot.ant"
    name="myapp" default="build">

    <property name="spring-boot.version" value="3.1.3" />

    <target name="resolve" description="--> retrieve dependencies with ivy">
        <ivy:retrieve pattern="lib/[conf]/[artifact]-[type]-[revision].[ext]" />
    </target>

    <target name="classpaths" depends="resolve">
        <path id="compile.classpath">
            <fileset dir="lib/compile" includes="*.jar" />
        </path>
    </target>

    <target name="init" depends="classpaths">
        <mkdir dir="build/classes" />
    </target>

    <target name="compile" depends="init" description="compile">
        <javac srcdir="src/main/java" destdir="build/classes" classpathref="compile.classpath" />
    </target>

    <target name="build" depends="compile">
        <spring-boot:exejar destfile="build/myapp.jar" classes="build/classes">
            <spring-boot:lib>
                <fileset dir="lib/runtime" />
            </spring-boot:lib>
        </spring-boot:exejar>
    </target>
</project>
Если вы не хотите использовать модуль spring-boot-antlib, см. раздел howto.html “Как сделать”.

1.5. Starters

Starters — это набор удобных описателей зависимостей, которые можно включить в ваше приложение. Вы получаете единый инструмент для всех необходимых технологий Spring и связанных технологий, без необходимости поиска в примерах кода и копирования-вставки множества описаний зависимостей. Например, если вы хотите начать работу с Spring и JPA для доступа к базе данных, включите зависимость spring-boot-starter-data-jpa в ваш проект.

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

Что скрывается в названии

Все официальные starters следуют схожему шаблону именования; spring-boot-starter-*, где * — определённый тип приложения. Данная структура именования предназначена для помощи при поиске starters. Интеграция Maven во многих IDE позволяет искать зависимости по имени. Например, с установленным соответствующим плагином Eclipse или Spring Tools, вы можете нажать ctrl-space в редакторе POM и ввести “spring-boot-starter” для получения полного списка.

Как объясняется в разделе “Создание собственного Starter”, starters сторонних разработчиков не должны начинаться с spring-boot, так как это зарезервировано для официальных артефактов Spring Boot. Вместо этого starter стороннего разработчика обычно начинается с названия проекта. Например, проект starter стороннего разработчика, названный thirdpartyproject, обычно называется thirdpartyproject-spring-boot-starter.

Следующие starters для приложений предоставляются Spring Boot под группой org.springframework.boot.

Таблица 1. Starters Spring Boot для приложений
Имя Описание

spring-boot-starter

Основной стартер, включая поддержку автоматической конфигурации, ведение журнала и YAML

spring-boot-starter-activemq

Стартер для обмена сообщениями JMS с использованием Apache ActiveMQ

spring-boot-starter-amqp

Стартер для использования Spring AMQP и Rabbit MQ

spring-boot-starter-aop

Стартер для программирования с аспектно-ориентированной моделью с Spring AOP и AspectJ

spring-boot-starter-artemis

Стартер для обмена сообщениями JMS с использованием Apache Artemis

spring-boot-starter-batch

Стартер для использования Spring Batch

spring-boot-starter-cache

Стартер для использования поддержки кэширования Spring Framework

spring-boot-starter-data-cassandra

Стартер для использования распределённой базы данных Cassandra и Spring Data Cassandra

spring-boot-starter-data-cassandra-reactive

Стартер для использования распределённой базы данных Cassandra и Spring Data Cassandra Reactive

spring-boot-starter-data-couchbase

Стартер для использования документоориентированной базы данных Couchbase и Spring Data Couchbase

spring-boot-starter-data-couchbase-reactive

Стартер для использования документоориентированной базы данных Couchbase и Spring Data Couchbase Reactive

spring-boot-starter-data-elasticsearch

Стартер для использования поискового и аналитического движка Elasticsearch и Spring Data Elasticsearch

spring-boot-starter-data-jdbc

Стартер для использования Spring Data JDBC

spring-boot-starter-data-jpa

Стартер для использования Spring Data JPA с Hibernate

spring-boot-starter-data-ldap

Стартер для использования Spring Data LDAP

spring-boot-starter-data-mongodb

Стартер для использования документоориентированной базы данных MongoDB и Spring Data MongoDB

spring-boot-starter-data-mongodb-reactive

Стартер для использования документоориентированной базы данных MongoDB и Spring Data MongoDB Reactive

spring-boot-starter-data-neo4j

Стартер для использования графовой базы данных Neo4j и Spring Data Neo4j

spring-boot-starter-data-r2dbc

Стартер для использования Spring Data R2DBC

spring-boot-starter-data-redis

Стартер для использования хранилища данных Redis с ключами и значениями, Spring Data Redis и клиентом Lettuce

spring-boot-starter-data-redis-reactive

Стартер для использования хранилища данных Redis с ключами и значениями, Spring Data Redis Reactive и клиентом Lettuce

spring-boot-starter-data-rest

Стартер для экспонирования репозиториев Spring Data через REST с помощью Spring Data REST и Spring MVC

spring-boot-starter-freemarker

Стартер для создания веб-приложений MVC с использованием представлений FreeMarker

spring-boot-starter-graphql

Стартер для создания приложений GraphQL с Spring GraphQL

spring-boot-starter-groovy-templates

Стартер для создания веб-приложений MVC с использованием представлений Groovy Templates

spring-boot-starter-hateoas

Стартер для создания гипермедийно-ориентированных RESTful веб-приложений с Spring MVC и Spring HATEOAS

spring-boot-starter-integration

Стартер для использования Spring Integration

spring-boot-starter-jdbc

Стартер для использования JDBC с пулом подключений HikariCP

spring-boot-starter-jersey

Стартер для создания RESTful веб-приложений с использованием JAX-RS и Jersey. Альтернатива spring-boot-starter-web

spring-boot-starter-jooq

Стартер для использования jOOQ для доступа к базам данных SQL с JDBC. Альтернатива spring-boot-starter-data-jpa или spring-boot-starter-jdbc

spring-boot-starter-json

Стартер для чтения и записи JSON

spring-boot-starter-mail

Стартер для использования Java Mail и поддержки отправки писем Spring Framework

spring-boot-starter-mustache

Стартер для создания веб-приложений с использованием представлений Mustache

spring-boot-starter-oauth2-authorization-server

Стартер для использования функций Spring Authorization Server

spring-boot-starter-oauth2-client

Стартер для использования функций клиента OAuth2/OpenID Connect Spring Security

spring-boot-starter-oauth2-resource-server

Стартер для использования функций ресурсного сервера OAuth2 Spring Security

spring-boot-starter-quartz

Стартер для использования планировщика Quartz

spring-boot-starter-rsocket

Стартер для создания клиентов и серверов RSocket

spring-boot-starter-security

Стартер для использования Spring Security

spring-boot-starter-test

Стартер для тестирования приложений Spring Boot с библиотеками, включая JUnit Jupiter, Hamcrest и Mockito

spring-boot-starter-thymeleaf

Стартер для создания веб-приложений MVC с использованием представлений Thymeleaf

spring-boot-starter-validation

Стартер для использования Java Bean Validation с Hibernate Validator

spring-boot-starter-web

Стартер для создания веб-приложений, включая RESTful, с использованием Spring MVC. Использует Tomcat в качестве контейнера по умолчанию

spring-boot-starter-web-services

Стартер для использования Spring Web Services

spring-boot-starter-webflux

Стартер для создания приложений WebFlux с использованием реактивной поддержки веб-приложений Spring Framework

spring-boot-starter-websocket

Запускаемый модуль для создания приложений WebSocket с использованием поддержки WebSocket Spring Framework MVC

Помимо стартовых наборов приложений, можно использовать следующие стартовые наборы для добавления функций «готовых к производству»:

Таблица 2. Стартовые наборы Spring Boot для производства
Название Описание

spring-boot-starter-actuator

Стартовый набор для использования Spring Boot Actuator, который предоставляет готовые к производству функции для мониторинга и управления вашим приложением

Наконец, Spring Boot также включает следующие стартовые наборы, которые можно использовать, если вы хотите исключить или заменить определённые технические аспекты:

Таблица 3. Технические стартовые наборы Spring Boot
Название Описание

spring-boot-starter-jetty

Стартовый набор для использования Jetty в качестве встроенного контейнера сервлетов. Альтернатива spring-boot-starter-tomcat

spring-boot-starter-log4j2

Стартовый набор для использования Log4j2 для ведения журналов. Альтернатива spring-boot-starter-logging

spring-boot-starter-logging

Стартовый набор для ведения журналов с помощью Logback. Стартовый набор для ведения журналов по умолчанию

spring-boot-starter-reactor-netty

Стартовый набор для использования Reactor Netty в качестве встроенного реактивного HTTP-сервера.

spring-boot-starter-tomcat

Стартовый набор для использования Tomcat в качестве встроенного контейнера сервлетов. Стартовый набор контейнера сервлетов по умолчанию, используемый spring-boot-starter-web

spring-boot-starter-undertow

Стартовый набор для использования Undertow в качестве встроенного контейнера сервлетов. Альтернатива spring-boot-starter-tomcat

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

Список дополнительных стартовых наборов, предоставленных сообществом, см. в файле README в модуле spring-boot-starters на GitHub.

2. Структурирование кода

Spring Boot не требует определённой структуры кода для работы. Однако существуют лучшие практики, которые помогают.

2.1. Использование пакета «по умолчанию»

Когда класс не содержит объявления пакета, он считается находящимся в пакете «по умолчанию». Использование пакета «по умолчанию» в целом не рекомендуется и следует избегать. Оно может вызвать особые проблемы для приложений Spring Boot, использующих аннотации @ComponentScan, @ConfigurationPropertiesScan, @EntityScan, или @SpringBootApplication, поскольку каждый класс из каждого JAR-файла читается.

Рекомендуется следовать рекомендуемым соглашениям по именованию пакетов Java и использовать обратный домен (например, com.example.project).

2.2. Позиционирование главного класса приложения

Мы рекомендуем размещать главный класс приложения в корневом пакете над другими классами. Аннотация @SpringBootApplication часто размещается на вашем главном классе, и она неявно определяет базовый «поисковый пакет» для некоторых элементов. Например, если вы пишете приложение JPA, пакет класса, помеченного аннотацией @SpringBootApplication, используется для поиска элементов @Entity. Использование корневого пакета также позволяет сканированию компонентов применяться только к вашему проекту.

Если вы не хотите использовать @SpringBootApplication, аннотации @EnableAutoConfiguration и @ComponentScan , которые он импортирует, определяют это поведение, поэтому вы также можете использовать их вместо него.

Следующий список демонстрирует типичную структуру:

com
 +- example
     +- myapplication
         +- MyApplication.java
         |
         +- customer
         |   +- Customer.java
         |   +- CustomerController.java
         |   +- CustomerService.java
         |   +- CustomerRepository.java
         |
         +- order
             +- Order.java
             +- OrderController.java
             +- OrderService.java
             +- OrderRepository.java

Файл MyApplication.java объявит метод main вместе с базовым @SpringBootApplication, как показано ниже:

Java
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}
Kotlin
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication

@SpringBootApplication
class MyApplication

fun main(args: Array<String>) {
    runApplication<MyApplication>(*args)
}

3. Классы конфигурации

Spring Boot отдаёт предпочтение конфигурации на основе Java. Хотя можно использовать SpringApplication с XML-источниками, мы в целом рекомендуем, чтобы вашим основным источником был один класс @Configuration . Обычно класс, который определяет метод main , является хорошим кандидатом в качестве основного @Configuration.

Много примеров конфигурации Spring опубликовано в Интернете, которые используют XML-конфигурацию. Если возможно, всегда старайтесь использовать эквивалентную конфигурацию на основе Java. Поиск аннотаций Enable* может стать хорошим началом.

3.1. Импорт дополнительных классов конфигурации

Вам не нужно помещать все ваши @Configuration в один класс. Аннотация @Import может использоваться для импорта дополнительных классов конфигурации. В качестве альтернативы, вы можете использовать @ComponentScan для автоматического подбора всех компонентов Spring, включая классы @Configuration.

3.2. Импорт XML-конфигурации

Если вам абсолютно необходимо использовать конфигурацию на основе XML, мы рекомендуем всё же начать с класса @Configuration. Затем вы можете использовать аннотацию @ImportResource для загрузки XML-файлов конфигурации.

4. Автоконфигурация

Автоконфигурация Spring Boot пытается автоматически сконфигурировать ваше Spring-приложение на основе добавленных зависимостей jar. Например, если HSQLDB находится в вашем classpath, и вы не вручную сконфигурировали какие-либо бины подключения к базе данных, то Spring Boot автоматически настраивает базу данных в памяти.

Для использования автоконфигурации необходимо добавить аннотации @EnableAutoConfiguration или @SpringBootApplication в один из ваших @Configuration классов.

Вы должны добавить только одну аннотацию @SpringBootApplication или @EnableAutoConfiguration. Мы обычно рекомендуем добавить одну или другую в ваш основной @Configuration класс.

4.1. Постепенная замена автоконфигурации

Автоконфигурация неинвазивная. В любой момент вы можете начать определять собственную конфигурацию для замены определенных частей автоконфигурации. Например, если вы добавите свой собственный бин DataSource, поддержка встроенной базы данных по умолчанию отключается.

Если вам нужно узнать, какая автоконфигурация в данный момент применяется и почему, запустите приложение с переключателем --debug. Это включит отладочные логи для ряда основных логгеров и выведет отчет о условиях в консоль.

4.2. Отключение определенных классов автоконфигурации

Если вы обнаружите, что применяются определенные классы автоконфигурации, которых вы не хотите, вы можете использовать атрибут exclude аннотации @SpringBootApplication, чтобы отключить их, как показано в следующем примере:

Java
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
public class MyApplication {

}
Kotlin
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

@SpringBootApplication(exclude = [DataSourceAutoConfiguration::class])
class MyApplication

Если класс отсутствует в classpath, вы можете использовать атрибут excludeName аннотации и указать полное имя вместо этого. Если вы предпочитаете использовать @EnableAutoConfiguration вместо @SpringBootApplication, exclude и excludeName также доступны. Наконец, вы также можете контролировать список классов автоконфигурации, которые нужно исключить, используя свойство spring.autoconfigure.exclude.

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

5. Компоненты Spring и внедрение зависимостей

Вы можете использовать любые стандартные методы Spring Framework для определения своих бинов и внедренных зависимостей. Мы обычно рекомендуем использовать внедрение через конструктор для подключения зависимостей и @ComponentScan для поиска бинов.

Если вы структурируете свой код как указано выше (располагая класс приложения в верхнем пакете), вы можете добавить @ComponentScan без каких-либо аргументов или использовать аннотацию @SpringBootApplication, которая подразумевает её включение. Все компоненты вашего приложения (@Component, @Service, @Repository, @Controller и другие) автоматически регистрируются как Spring бины.

Следующий пример показывает бин @Service, который использует внедрение через конструктор для получения необходимого бина RiskAssessor.

Java
import org.springframework.stereotype.Service;

@Service
public class MyAccountService implements AccountService {

    private final RiskAssessor riskAssessor;

    public MyAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
    }

    // ...

}
Kotlin
import org.springframework.stereotype.Service

@Service
class MyAccountService(private val riskAssessor: RiskAssessor) : AccountService

Если у бина более одного конструктора, вам нужно пометить тот, который вы хотите использовать Spring, аннотацией @Autowired.

Java
import java.io.PrintStream;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class MyAccountService implements AccountService {

    private final RiskAssessor riskAssessor;

    private final PrintStream out;

    @Autowired
    public MyAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
        this.out = System.out;
    }

    public MyAccountService(RiskAssessor riskAssessor, PrintStream out) {
        this.riskAssessor = riskAssessor;
        this.out = out;
    }

    // ...

}
Kotlin
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.stereotype.Service
import java.io.PrintStream

@Service
class MyAccountService : AccountService {

    private val riskAssessor: RiskAssessor

    private val out: PrintStream

    @Autowired
    constructor(riskAssessor: RiskAssessor) {
        this.riskAssessor = riskAssessor
        out = System.out
    }

    constructor(riskAssessor: RiskAssessor, out: PrintStream) {
        this.riskAssessor = riskAssessor
        this.out = out
    }

    // ...

}
Обратите внимание, как использование внедрения через конструктор позволяет пометить поле riskAssessor как final, что означает, что его нельзя изменить после этого.

6. Использование аннотации @SpringBootApplication

Многие разработчики Spring Boot любят, чтобы их приложения использовали автоконфигурацию, сканирование компонентов и возможность определять дополнительную конфигурацию в своем «прикладном классе». Единая аннотация @SpringBootApplication может использоваться для включения этих трёх функций:

  • @EnableAutoConfiguration: включение механизма автоконфигурации Spring Boot

  • @ComponentScan: включение сканирования @Component в пакете, где расположено приложение (см. лучшие практики)

  • @SpringBootConfiguration: включение регистрации дополнительных бинов в контексте или импорта дополнительных классов конфигурации. Альтернатива стандартному @Configuration Spring, которая помогает обнаружению конфигурации в ваших интеграционных тестах.

Java
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

// Same as @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan
@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}
Kotlin
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication

// same as @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan
@SpringBootApplication
class MyApplication

fun main(args: Array<String>) {
    runApplication<MyApplication>(*args)
}
@SpringBootApplication также предоставляет псевдонимы для настройки атрибутов @EnableAutoConfiguration и @ComponentScan.

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

Java
import org.springframework.boot.SpringApplication;
import org.springframework.boot.SpringBootConfiguration;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.Import;

@SpringBootConfiguration(proxyBeanMethods = false)
@EnableAutoConfiguration
@Import({ SomeConfiguration.class, AnotherConfiguration.class })
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }

}
Kotlin
import org.springframework.boot.SpringBootConfiguration
import org.springframework.boot.autoconfigure.EnableAutoConfiguration
import org.springframework.boot.docs.using.structuringyourcode.locatingthemainclass.MyApplication
import org.springframework.boot.runApplication
import org.springframework.context.annotation.Import

@SpringBootConfiguration(proxyBeanMethods = false)
@EnableAutoConfiguration
@Import(SomeConfiguration::class, AnotherConfiguration::class)
class MyApplication

fun main(args: Array<String>) {
    runApplication<MyApplication>(*args)
}

В этом примере MyApplication такой же, как и любое другое Spring Boot приложение, за исключением того, что классы с аннотацией @Component и классы с аннотацией @ConfigurationProperties не обнаруживаются автоматически, и пользовательские бины импортируются явно (см. @Import).

7. Запуск вашего приложения

Одним из главных преимуществ упаковки приложения в jar-файл и использования встроенного HTTP-сервера является возможность запуска приложения как любого другого. Пример относится к отладке приложений Spring Boot. Вам не нужны никакие специальные плагины или расширения для IDE.

Данный раздел охватывает только упаковку в формате jar. Если вы выбираете упаковку приложения в виде файла war, обратитесь к документации вашего сервера и IDE.

7.1. Запуск из IDE

Вы можете запустить приложение Spring Boot из вашей IDE как Java-приложение. Однако для этого сначала необходимо импортировать проект. Шаги импорта зависят от вашей IDE и системы сборки. Большинство IDE могут импортировать Maven-проекты напрямую. Например, пользователи Eclipse могут выбрать Import…​ → Existing Maven Projects из меню File.

Если вы не можете напрямую импортировать свой проект в IDE, вы можете сгенерировать метаданные IDE, используя плагин сборки. Maven включает плагины для Eclipse и IDEA. Gradle предлагает плагины для различных IDE.

Если вы случайно запустите веб-приложение дважды, вы увидите ошибку «Порт уже используется». Пользователи Spring Tools могут использовать кнопку Relaunch, а не кнопку Run, чтобы убедиться, что любой существующий экземпляр закрыт.

7.2. Запуск как упакованного приложения

Если вы используете плагины Spring Boot Maven или Gradle для создания исполняемого jar-файла, вы можете запустить ваше приложение, используя java -jar, как показано в следующем примере:

$ java -jar target/myapplication-0.0.1-SNAPSHOT.jar

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

$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \
       -jar target/myapplication-0.0.1-SNAPSHOT.jar

7.3. Использование плагина Maven

Плагин Spring Boot Maven включает цель run, которую можно использовать для быстрого компиляции и запуска вашего приложения. Приложения запускаются в развернутой форме, как и в вашей IDE. Следующий пример демонстрирует типичную Maven команду для запуска приложения Spring Boot:

$ mvn spring-boot:run

Вы также можете использовать переменную среды операционной системы MAVEN_OPTS, как показано в следующем примере:

$ export MAVEN_OPTS=-Xmx1024m

7.4. Использование плагина Gradle

Плагин Spring Boot Gradle также включает задачу bootRun, которая может использоваться для запуска вашего приложения в развернутой форме. Задача bootRun добавляется всякий раз, когда вы применяете плагины org.springframework.boot и java, и показана в следующем примере:

$ gradle bootRun

Вы также можете использовать переменную среды операционной системы JAVA_OPTS, как показано в следующем примере:

$ export JAVA_OPTS=-Xmx1024m

7.5. Горячая замена

Поскольку приложения Spring Boot являются обычными Java-приложениями, горячая замена JVM должна работать прямо из коробки. Горячая замена JVM несколько ограничена по байткоду, который она может заменить. Для более полного решения можно использовать JRebel.

Модуль spring-boot-devtools также включает поддержку быстрой перезагрузки приложения. Подробности см. в разделе «Горячая замена».

Инструменты разработчика

Spring Boot включает дополнительный набор инструментов, которые могут сделать процесс разработки приложений немного приятнее. Модуль spring-boot-devtools может быть включён в любой проект для предоставления дополнительных функций во время разработки. Чтобы включить поддержку devtools, добавьте зависимость модуля в свой билдовый файл, как показано в следующих примерах для Maven и Gradle:

Maven
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>
Gradle
dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
}
Devtools может вызывать проблемы с загрузкой классов, особенно в проектах с множеством модулей. Раздел Диагностика проблем с загрузкой классов объясняет, как их диагностировать и решать.
Инструменты разработчика автоматически отключаются при запуске полностью упакованного приложения. Если ваше приложение запускается из java -jar или если оно запускается из специального загрузчика классов, то оно считается «приложением для производства». Вы можете контролировать это поведение с помощью системной переменной spring.devtools.restart.enabled. Чтобы включить devtools независимо от загрузчика классов, используемого для запуска вашего приложения, установите системную переменную -Dspring.devtools.restart.enabled=true. Этого нельзя делать в производственной среде, где запуск devtools представляет собой риск для безопасности. Чтобы отключить devtools, исключите зависимость или установите системную переменную -Dspring.devtools.restart.enabled=false.
Отметив зависимость как необязательную в Maven или используя конфигурацию developmentOnly в Gradle (как показано выше), вы предотвращаете транзитивное применение devtools к другим модулям, использующим ваш проект.
Переупакованные архивы по умолчанию не содержат devtools. Если вы хотите использовать определённую удалённую функцию devtools, вам необходимо включить её. При использовании плагина Maven, установите свойство excludeDevtools в false. При использовании плагина Gradle, настройте путь к классам задачи, включив конфигурацию developmentOnly.

8.1. Диагностика проблем с загрузкой классов

Как описано в разделе Перезапуск vs Перезагрузка, функциональность перезапуска реализована с использованием двух загрузчиков классов. Для большинства приложений этот подход работает хорошо. Однако иногда это может вызвать проблемы с загрузкой классов, особенно в проектах с множеством модулей.

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

8.2. Значения свойств по умолчанию

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

Хотя кэширование очень полезно в производстве, оно может быть неэффективным во время разработки, мешая вам видеть изменения, которые вы только что внесли в своё приложение. По этой причине spring-boot-devtools по умолчанию отключает кэширование.

Параметры кэширования обычно конфигурируются в файле application.properties. Например, Thymeleaf предлагает свойство spring.thymeleaf.cache. Вместо необходимости устанавливать эти свойства вручную, модуль spring-boot-devtools автоматически применяет разумную конфигурацию во время разработки.

В следующей таблице перечислены все применяемые свойства:

Имя Значение по умолчанию

server.error.include-binding-errors

always

server.error.include-message

always

server.error.include-stacktrace

always

server.servlet.jsp.init-parameters.development

true

server.servlet.session.persistent

true

spring.docker.compose.readiness.wait

only-if-started

spring.freemarker.cache

false

spring.graphql.graphiql.enabled

true

spring.groovy.template.cache

false

spring.h2.console.enabled

true

spring.mustache.servlet.cache

false

spring.mvc.log-resolved-exception

true

spring.reactor.netty.shutdown-quiet-period

0s

spring.template.provider.cache

false

spring.thymeleaf.cache

false

spring.web.resources.cache.period

0

spring.web.resources.chain.cache

false

Если вы не хотите, чтобы применялись значения свойств по умолчанию, вы можете установить spring.devtools.add-properties на false в своём файле application.properties.

Поскольку вам требуется больше информации о веб-запросах во время разработки приложений Spring MVC и Spring WebFlux, инструменты разработчика рекомендуют включить DEBUG логирование для группы логирования web. Это даст вам информацию об входящем запросе, обработчике, который его обрабатывает, результате ответа и других деталях. Если вы хотите вести журнал всех деталей запроса (включая потенциально конфиденциальную информацию), вы можете включить свойства конфигурации spring.mvc.log-request-details или spring.codec.log-request-details.

8.3. Автоматическое перезапуска

Приложения, использующие spring-boot-devtools, автоматически перезапускаются всякий раз, когда изменяются файлы в классе. Это может быть полезной функцией при работе в IDE, поскольку она обеспечивает очень быструю обратную связь для изменений кода. По умолчанию отслеживаются изменения любых записей в пути класса, которые указывают на директорию. Обратите внимание, что некоторые ресурсы, такие как статические активы и шаблоны представлений, не требуют перезапуска приложения.

Вызвать перезапуск

Поскольку DevTools отслеживает ресурсы пути класса, единственный способ вызвать перезапуск — обновить путь класса. Независимо от того, используете ли вы IDE или один из плагинов сборки, изменённые файлы должны быть перекомпилированы, чтобы вызвать перезапуск. Способ обновления пути класса зависит от используемого инструмента:

  • В Eclipse сохранение изменённого файла приводит к обновлению пути класса и вызывает перезапуск.

  • В IntelliJ IDEA построение проекта (Build +→+ Build Project) имеет тот же эффект.

  • При использовании плагина сборки запуск mvn compile для Maven или gradle build для Gradle вызовет перезапуск.

Если вы перезапускаете приложение с помощью Maven или Gradle, используя плагин сборки, вы должны оставить forking установленным в enabled. Если вы отключите форкинг, изолированный загрузчик классов приложения, используемый devtools, не будет создан, и перезапуски не будут работать должным образом.
Автоматический перезапуск очень хорошо работает в сочетании с LiveReload. См. раздел LiveReload для получения подробностей. Если вы используете JRebel, автоматические перезапуски отключены в пользу динамической перезагрузки классов. Другие функции devtools (такие как LiveReload и переопределения свойств) по-прежнему могут использоваться.
DevTools полагается на хук завершения работы контекста приложения для его закрытия во время перезапуска. Он не работает должным образом, если вы отключили хук завершения работы (SpringApplication.setRegisterShutdownHook(false)).
DevTools необходимо настроить ResourceLoader используемый ApplicationContext. Если ваше приложение уже предоставляет его, оно будет обернуто. Прямое переопределение метода getResource в ApplicationContext не поддерживается.
Автоматический перезапуск не поддерживается при использовании AspectJ weaving.
Перезапуск против перезагрузки

Технология перезапуска, предоставляемая Spring Boot, работает с использованием двух загрузчиков классов. Классы, которые не изменяются (например, те, что из библиотек третьих сторон), загружаются в базовый загрузчик классов. Классы, которые активно разрабатываются, загружаются в перезапускаемый загрузчик классов. При перезапуске приложения перезапускаемый загрузчик классов удаляется, и создаётся новый. Этот подход означает, что перезапуск приложения обычно намного быстрее, чем «холодный запуск», так как базовый загрузчик классов уже доступен и заполнен.

Если вы обнаружите, что перезапуски недостаточно быстры для ваших приложений или столкнётесь с проблемами загрузки классов, вы можете рассмотреть технологии перезагрузки, такие как JRebel от ZeroTurnaround. Они работают путём переписывания классов по мере их загрузки, чтобы сделать их более подходящими для перезагрузки.

8.3.1. Ведение логов изменений в оценке условий

По умолчанию каждый раз, когда ваше приложение перезапускается, регистрируется отчёт, показывающий разницу в оценке условий. Отчёт показывает изменения в автоматической настройке вашего приложения по мере внесения изменений, таких как добавление или удаление бинов и установка свойств конфигурации.

Чтобы отключить регистрацию отчёта, установите следующее свойство:

Свойства
spring.devtools.restart.log-condition-evaluation-delta=false
Yaml
spring:
  devtools:
    restart:
      log-condition-evaluation-delta: false

8.3.2. Исключение ресурсов

Некоторые ресурсы не обязательно должны вызывать перезапуск при изменении. Например, шаблоны Thymeleaf можно редактировать непосредственно. По умолчанию изменение ресурсов в /META-INF/maven, /META-INF/resources, /resources, /static, /public, или /templates не вызывает перезапуск, но вызывает немедленную перезагрузку. Если вы хотите настроить эти исключения, вы можете использовать свойство spring.devtools.restart.exclude. Например, чтобы исключить только /static и /public, вы бы установили следующее свойство:

Свойства
spring.devtools.restart.exclude=static/**,public/**
Yaml
spring:
  devtools:
    restart:
      exclude: "static/**,public/**"
Если вы хотите сохранить эти значения по умолчанию и добавить дополнительные исключения, используйте свойство spring.devtools.restart.additional-exclude вместо него.

8.3.3. Отслеживание дополнительных путей

Возможно, вы захотите, чтобы ваше приложение перезапускалось или перезагружалось при внесении изменений в файлы, которые не находятся в пути класса. Для этого используйте свойство spring.devtools.restart.additional-paths для настройки дополнительных путей для отслеживания изменений. Вы можете использовать свойство spring.devtools.restart.exclude описанное ранее для управления тем, вызывают ли изменения под дополнительными путями полный перезапуск или немедленную перезагрузку.

8.3.4. Отключение перезапуска

Если вы не хотите использовать функцию перезапуска, вы можете отключить её с помощью свойства spring.devtools.restart.enabled. В большинстве случаев вы можете установить это свойство в вашем application.properties (при этом загрузчик перезапускающего класса всё ещё инициализируется, но отслеживание изменений файлов не происходит).

Если вам нужно полностью отключить поддержку перезапуска (например, потому что она не работает со специфической библиотекой), вам нужно установить свойство spring.devtools.restart.enabled System в значение false до вызова SpringApplication.run(…​), как показано в следующем примере:

Java
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        System.setProperty("spring.devtools.restart.enabled", "false");
        SpringApplication.run(MyApplication.class, args);
    }

}
Kotlin
import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication

@SpringBootApplication
object MyApplication {

    @JvmStatic
    fun main(args: Array<String>) {
        System.setProperty("spring.devtools.restart.enabled", "false")
        SpringApplication.run(MyApplication::class.java, *args)
    }

}

8.3.5. Использование файла триггера

Если вы работаете с IDE, которая непрерывно компилирует изменённые файлы, вы можете предпочесть вызывать перезапуск только в определённые моменты времени. Для этого можно использовать «файл триггера», который является специальным файлом, который необходимо изменить, когда вы хотите фактически вызвать проверку перезапуска.

Любое обновление файла вызовет проверку, но перезапуск произойдёт только в том случае, если Devtools обнаружит, что нужно что-то сделать.

Для использования файла триггера установите свойство spring.devtools.restart.trigger-file в имя (без пути) вашего файла триггера. Файл триггера должен быть где-то в пути класса.

Например, если у вас есть проект со следующей структурой:

src
+- main
   +- resources
      +- .reloadtrigger

Тогда ваше свойство trigger-file будет:

Свойства
spring.devtools.restart.trigger-file=.reloadtrigger
Yaml
spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

Перезапуск теперь будет происходить только тогда, когда обновляется src/main/resources/.reloadtrigger.

Возможно, вы захотите установить spring.devtools.restart.trigger-file в качестве глобальной настройки, чтобы все ваши проекты работали одинаково.

Некоторые IDE имеют функции, которые избавляют вас от необходимости вручную обновлять файл триггера. Spring Tools for Eclipse и IntelliJ IDEA (Ultimate Edition) обе поддерживают это. С Spring Tools вы можете использовать кнопку «перезагрузить» из консоли (пока ваш trigger-file назван .reloadtrigger). Для IntelliJ IDEA вы можете следовать инструкциям в их документации .

8.3.6. Настройка загрузчика класса Restart

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

По умолчанию любой открытый проект в вашем IDE загружается с загрузчиком «restart», а любой обычный .jar файл загружается с загрузчиком «base». То же самое верно, если вы используете mvn spring-boot:run или gradle bootRun: проект, содержащий ваш @SpringBootApplication загружается с загрузчиком «restart», а все остальное — с загрузчиком «base».

Вы можете указать Spring Boot на загрузку частей вашего проекта с помощью другого загрузчика, создав META-INF/spring-devtools.properties файл. spring-devtools.properties файл может содержать свойства, префикс которых restart.exclude и restart.include. Элементы include — это элементы, которые должны быть загружены в загрузчик «restart», а элементы exclude — это элементы, которые должны быть загружены в загрузчик «base». Значение свойства — это шаблон регулярного выражения, который применяется к пути класса, как показано в следующем примере:

Свойства
restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\\.]+\\.jar
restart.include.projectcommon=/mycorp-myproj-[\\w\\d-\\.]+\\.jar
Yaml
restart:
  exclude:
    companycommonlibs: "/mycorp-common-[\\w\\d-\\.]+\\.jar"
  include:
    projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"
Все ключи свойств должны быть уникальными. До тех пор, пока свойство начинается с restart.include. или restart.exclude., оно считается.
Все META-INF/spring-devtools.properties из пути класса загружаются. Вы можете упаковать файлы внутри вашего проекта или в библиотеках, которые использует проект.

8.3.7. Известные ограничения

Функциональность перезапуска плохо работает с объектами, которые десериализуются с помощью стандартного ObjectInputStream. Если вам нужно десериализовать данные, вам может потребоваться использовать Spring ConfigurableObjectInputStream в сочетании с Thread.currentThread().getContextClassLoader().

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

8.4. LiveReload

Модуль spring-boot-devtools включает встроенный сервер LiveReload, который можно использовать для запуска обновления браузера при изменении ресурса. Расширения LiveReload для браузеров доступны для Chrome, Firefox и Safari на livereload.com.

Если вы не хотите запускать сервер LiveReload при запуске приложения, вы можете установить свойство spring.devtools.livereload.enabled в значение false.

Вы можете запустить только один сервер LiveReload за раз. Перед запуском приложения убедитесь, что другие серверы LiveReload не работают. Если вы запускаете несколько приложений из IDE, только первое поддерживает LiveReload.
Для запуска LiveReload при изменении файла должен быть включен Автоматический перезапуск.

8.5. Глобальные настройки

Вы можете настроить глобальные настройки devtools, добавив любой из следующих файлов в каталог $HOME/.config/spring-boot:

  1. spring-boot-devtools.properties

  2. spring-boot-devtools.yaml

  3. spring-boot-devtools.yml

Любые свойства, добавленные в эти файлы, применяются ко всем приложениям Spring Boot на вашей машине, использующим devtools. Например, чтобы настроить перезапуск для всегда использования триггерного файла, добавьте следующее свойство в ваш файл spring-boot-devtools:

Свойства
spring.devtools.restart.trigger-file=.reloadtrigger
Yaml
spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

По умолчанию, $HOME — это домашний каталог пользователя. Чтобы настроить это местоположение, установите переменную среды SPRING_DEVTOOLS_HOME или системную переменную spring.devtools.home.

Если файлы конфигурации devtools не найдены в $HOME/.config/spring-boot, ищется присутствие файла .spring-boot-devtools.properties в корне каталога $HOME. Это позволяет делиться глобальной конфигурацией devtools с приложениями, которые находятся на более старой версии Spring Boot, не поддерживающей расположение $HOME/.config/spring-boot .

Профили не поддерживаются в файлах свойств/yaml devtools.

Любые профили, активированные в .spring-boot-devtools.properties не повлияют на загрузку файлов конфигурации, специфичных для профиля. Не поддерживаются имена файлов, специфичные для профиля (в формате spring-boot-devtools-<profile>.properties) и spring.config.activate.on-profile документы в формате YAML и свойств.

8.5.1. Настройка монитора системы файлов

FileSystemWatcher работает, опрашивая изменения в классе с определённым интервалом времени и ожидая заранее определённого периода покоя, чтобы убедиться, что больше нет изменений. Поскольку Spring Boot полностью полагается на IDE для компиляции и копирования файлов в местоположение, откуда Spring Boot может их читать, вы можете столкнуться с ситуациями, когда некоторые изменения не отражаются при перезапуске приложения devtools. Если вы постоянно наблюдаете такие проблемы, попробуйте увеличить параметры spring.devtools.restart.poll-interval и spring.devtools.restart.quiet-period до значений, подходящих вашей среде разработки:

Свойства
spring.devtools.restart.poll-interval=2s
spring.devtools.restart.quiet-period=1s
Yaml
spring:
  devtools:
    restart:
      poll-interval: "2s"
      quiet-period: "1s"

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

8.6. Удаленные приложения

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

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

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>

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

Удаленная поддержка devtools предоставляется в двух частях: серверный конечный пункт, который принимает подключения, и клиентское приложение, которое вы запускаете в вашей IDE. Серверный компонент автоматически включается, когда установлено свойство spring.devtools.remote.secret. Клиентский компонент должен запускаться вручную.

Удаленная поддержка devtools не поддерживается для приложений Spring WebFlux.

8.6.1. Запуск удаленного клиентского приложения

Удаленное клиентское приложение предназначено для запуска из вашей IDE. Вам необходимо запустить org.springframework.boot.devtools.RemoteSpringApplication с тем же классовым путем, что и удаленный проект, к которому вы подключаетесь. Единственным обязательным аргументом приложения является удаленный URL-адрес, к которому оно подключается.

Например, если вы используете Eclipse или Spring Tools и у вас есть проект под названием my-app, который вы развернули в Cloud Foundry, вы выполните следующие действия:

  • Выберите Run Configurations…​ из меню Run.

  • Создайте новую Java Application «конфигурацию запуска».

  • Найдите проект my-app.

  • Используйте org.springframework.boot.devtools.RemoteSpringApplication в качестве главного класса.

  • Добавьте https://myapp.cfapps.io в Program arguments (или какой у вас удаленный URL).

Запущенный удаленный клиент может выглядеть следующим образом:

  .   ____          _                                              __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \
 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )
  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___|/ / / /
 =========|_|==============|___/===================================/_/_/_/
 :: Spring Boot Remote ::  (v3.1.3)

2023-08-24T09:33:20.700Z  INFO 37772 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication v3.1.3 using Java 17.0.8 with PID 37772 (/Users/myuser/.m2/repository/org/springframework/boot/spring-boot-devtools/3.1.3/spring-boot-devtools-3.1.3.jar started by myuser in /opt/apps/)
2023-08-24T09:33:20.707Z  INFO 37772 --- [           main] o.s.b.devtools.RemoteSpringApplication   : No active profile set, falling back to 1 default profile: "default"
2023-08-24T09:33:21.124Z  INFO 37772 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2023-08-24T09:33:21.160Z  INFO 37772 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 0.954 seconds (process running for 1.31)
Поскольку удаленный клиент использует тот же классовый путь, что и реальное приложение, он может непосредственно считывать свойства приложения. Вот как считывается и передается серверу для аутентификации свойство spring.devtools.remote.secret.
Всегда рекомендуется использовать https:// в качестве протокола подключения, чтобы трафик был зашифрован и пароли не могли быть перехвачены.
Если вам необходимо использовать прокси для доступа к удаленному приложению, настройте свойства spring.devtools.remote.proxy.host и spring.devtools.remote.proxy.port.

8.6.2. Удаленное обновление

Удаленный клиент отслеживает изменения в вашем классовом пути приложения таким же образом, как и локальная перезагрузка. Любой обновленный ресурс передается в удаленное приложение и (при необходимости) вызывает перезапуск. Это может быть полезно, если вы работаете над функцией, использующей облачную службу, которой у вас нет локально. Обычно удаленные обновления и перезапуски намного быстрее, чем цикл полной пересборки и развертывания.

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

Это обычно проявляется в виде предупреждения в журналах RemoteSpringApplication о невозможности загрузки некоторых классов и последующей повторной попытке. Но это также может привести к несогласованности кода приложения и невозможности перезапуска после загрузки первого пакета изменений. Если вы постоянно наблюдаете такие проблемы, попробуйте увеличить параметры spring.devtools.restart.poll-interval и spring.devtools.restart.quiet-period до значений, подходящих для вашей среды разработки. См. раздел Настройка монитора системы файлов для настройки этих свойств.

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

9. Упаковка приложения для производства

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

Для дополнительных функций «готовых к производству», таких как REST или JMX-конечные точки для мониторинга, аудита и метрик, рассмотрите возможность добавления spring-boot-actuator. Подробности см. в разделе actuator.html.

10. Что читать дальше

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

Copyright © 2012-2023 VMware, Inc.
Licensed under the Apache License, Version 2.0.
https://docs.spring.io/spring-boot/docs/3.1.3/reference/html/using.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API