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") }
Інструментальні засоби розробки автоматично деактивуються при виконанні повністю упакованої програми. Якщо ваша програма запускається через 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 конфігуруйте classpath для завдання так, щоб він містив конфігурацію developmentOnly .

Діагностика проблем із завантаженням класів

Функціональність перезапуску реалізована за допомогою двох завантажувачів класів. Для більшості програм такий підхід працює добре. Однак іноді він може призвести до проблем із завантаженням класів, особливо в багатомодульних проектах.

Щоб діагностувати, чи справді проблеми із завантаженням класів викликані devtools та їх двома завантажувачами класів, спробуйте вимкнути перезапуск. Якщо це вирішить ваші проблеми, налаштуйте перезапуск завантажувача класів на охоплення всього вашого проекту.

Властивості за замовчуванням

Деякі бібліотеки, що підтримуються 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.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.debug

true

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 у файлі < code>application.properties.

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

Автоматичний перезапуск

Програми, що використовують spring-boot-devtools, автоматично перезапускаються при зміні файлів у classpath. Це може бути корисною функцією при роботі в IDE, оскільки забезпечує дуже швидкий зворотний зв'язок для внесення змін до коду. За замовчуванням будь-який запис у classpath, що вказує на каталог, відстежується щодо змін. Зверніть увагу, що деякі ресурси, такі як статичний вміст та шаблони уявлень, не вимагають перезапуску програми.

Ініціація перезапуску

Оскільки DevTools відстежує ресурси в classpath, єдиним способом ініціювати перезапуск є оновлення classpath. Незалежно від того, чи використовуєте ви IDE або один із плагінів складання, змінені файли потрібно перекомпілювати, щоб ініціювати перезапуск. Спосіб оновлення classpath залежить від використовуваного інструменту:

  • В Eclipse збереження зміненого файлу призводить до оновлення classpath та ініціює перезапуск.

  • У IntelliJ IDEA складання проекту (Build +→+ Build Project) має той самий ефект.

  • Якщо використовується плагін складання, виконання mvn compile для Maven або gradle build для Gradle призведе до ініціації перезапуску.

Якщо перезапуск здійснюється за допомогою Maven або Gradle з використанням плагіна складання, то потрібно залишити значення forking, встановлене в enabled. Якщо ви відключите розгалуження (форкінг), ізольований завантажувач класів програми, що використовується devtools, не буде створено, а перезавантаження не буде працювати належним чином.
показує себе дуже добре під час використання з LiveReload. Якщо ви використовуєте JRebel, автоматичне перезавантаження вимкнено на користь динамічного перезавантаження класів. Інші функції devtools (такі як LiveReload і перевизначення властивостей), як і раніше, можна буде використовувати. перезапуску. Робота не буде коректною, якщо перехоплювач завершення вимкнений (SpringApplication.setRegisterShutdownHook(false)).
DevTools необхідно налаштувати завантажувач ResourceLoader, який використовується ApplicationContext. Якщо ваш додаток вже передбачає такий завантажувач, він буде обернутий. Пряме перевизначення методу getResource на ApplicationContext не підтримується.
Автоматичний перезапуск не підтримується під час використання прив'язки за допомогою AspectJ.
Перезапуск та перезавантаження

Технологія перезапуску, передбачена Spring Boot, працює за допомогою двох завантажувачів класів. Класи, які не змінюються (наприклад, класи зі сторонніх jar-файлів), завантажуються в основний завантажувач класів. Класи, які активно розробляються, завантажуються в завантажувач класів, що перезапускає. Якщо програма перезапускається, перезапуск завантажувач класів одночасно використовується, після чого створюється новий. Такий підхід означає, що перезапуск програми зазвичай відбувається набагато швидше, ніж "холодний запуск", оскільки основний завантажувач класів вже доступний і заповнений.

Якщо ви виявите, що перезавантаження недостатньо швидке для ваших програм або ви зіткнулися з проблемами завантаження класів, то можете ознайомитися з технологіями перезавантаження, такими як JRebel від ZeroTurnaround . Вони працюють шляхом переписування класів у міру їх завантаження, щоб вони були зручнішими для повторного завантаження. Перезапуск програми в журнал заноситься звіт, що показує дельту обчислення стану. Звіт демонструє зміни в автоконфігурації вашої програми в міру того, як ви вносите зміни, такі як додавання або видалення бінів і встановлення властивостей конфігурації. div class="spring-code-block spring-code-block--primary">

Properties
spring.devtools.restart.log-condition-evaluation-delta=false
Yaml
spring: devtools: restart: log-condition-evaluation-delta: false

Вилучення ресурсів

Деякі ресурси не обов'язково повинні ініціювати перезавантаження при їх зміні. Наприклад, шаблони Thymeleaf можна редагувати на тому ж місці. За умовчанням зміна ресурсів у /META-INF/maven, /META-INF/resources, /resources, /static, /public або /templates не ініціює перезапуск, але ініціює перезавантаження в реальному часі. Якщо ви бажаєте налаштувати ці винятки, то можете використовувати властивість spring.devtools.restart.exclude. Наприклад, щоб виключити лише /static та /public, потрібно встановити таку властивість:

Properties
spring.devtools.restart.exclude=static/**,public/**
Yaml
spring: devtools: restart: exclude: "static/**,public/**"
Якщо ви хочете зберегти ці значення за умовчанням і додати додаткові винятки, використовуйте властивість spring.devtools.restart.additional-exclude .

Відстеження додаткових шляхів

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

Вимкнення перезапуску

Якщо вам не потрібно використовувати функцію перезапуску, ви можете вимкнути її за допомогою властивості spring.devtools.restart.enabled. У більшості випадків можна встановити цю властивість у файлі application.properties (так все одно ініціалізуватиметься перезапускаючий завантажувач класів, але зміни файлів не будуть відстежуватися).

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

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:&ray≶ ) { System.setProperty("spring.devtools.restart.enabled", "false") SpringApplication.run(MyApplication::class.java, *args) } } 

Використання тригерного файлу

Якщо ви працюєте з IDE, яка постійно компілює файли, що змінюються, то можете віддати перевагу ініціації перезавантаження тільки в певні моменти. Для цього ви можете використовувати "тригерний файл", який є спеціалізованим файлом, який необхідно змінити, якщо ви дійсно хочете ініціювати перевірку перезапуску.

Будь-яке оновлення файлу викликає перевірку, але перезапуск відбувається тільки в тому випадку, якщо Devtools виявляють, що їм потрібно щось робити в ім'я (виключаючи шлях) вашого тригерного файлу. Тригерний файл повинен знаходитися десь у вашому classpath.

Наприклад, якщо у вас є проект із наступною структурою:

src +- main +- resources +- .reloadtrigger

Тоді властивість вашого trigger-file буде таким:

Properties
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 для Eclipse та IntelliJ IDEA (Ultimate Edition) мають такі засоби отримання. У Spring Tools ви можете використовувати кнопку "reload" з подання консолі (за умови, що ваш trigger-file має ім'я .reloadtrigger). У випадку з IntelliJ IDEA можна дотримуватися інструкцій у відповідній документації. a>.

Налаштування завантажувача класів, що перезапускає

Функціональність перезапуску реалізована через два завантажувача класів. Якщо виникають якісь проблеми, вам може знадобитися налаштувати, що і яким завантажувачем класів завантажуватиметься.

За замовчуванням будь-який відкритий проект у вашій IDE завантажується з завантажувачем класів, що перезапускає, а будь-який звичайний . jar-файл завантажується з "основним" завантажувачем класів. Те ж саме, якщо використовується mvn spring-boot:run або gradle bootRun: проект, що містить анотацію @SpringBootApplication, завантажується з "перезапускаючим" завантажувачем класу, а все інше – з "основним" завантажувачем класів.

Можна дати Spring Boot команду завантажувати компоненти проекту з іншим завантажувачем класів, створивши файл META-INF/spring-devtools.properties. Файл spring-devtools.properties може містити властивості з префіксами restart.exclude та restart.include. Елементи include - це компоненти, які потрібно підняти вгору в "завантажувач класів, що перезапускає", а елементи exclude - це елементи, які потрібно опустити вниз в "основний" завантажувач класів. Значення властивості є шаблоном регулярних виразів, який застосовується до classpath, як показано в наступному прикладі:

Properties
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 з classpath. Ви можете упаковувати файли всередині вашого проекту або в бібліотеках, які використовує проект. Якщо необхідно десеріалізувати дані, то може знадобитися використовувати ConfigurableObjectInputStream з Spring у поєднанні з Thread.currentThread().getContextClassLoader().

На жаль, деякі сторонні бібліотеки десеріалізують без урахування контекстного завантажувача класів. Якщо ви зіткнетеся з такою проблемою, необхідно буде запитати виправлення у авторів-творців.

LiveReload

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

Якщо запускати сервер LiveReload під час виконання програми не потрібно, то можна встановити властивість spring.devtools.livereload.enabled у false.

Одночасно можна запустити лише один сервер LiveReload. Перед запуском програми переконайтеся, що інші сервери LiveReload не запущені. Якщо ви запускаєте кілька програм з IDE, тільки перша з них підтримуватиме LiveReload.
Для ініціації функції LiveReload при зміні файлу, автоматичний перезапуск повинен бути увімкнений.

Глобальні параметри

Ви можете налаштувати глобальні параметри 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:

Properties
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, в корені каталогу $HOME буде здійснено пошук на предмет наявності файлу . spring-boot-devtools.properties. Це дозволить спільно використовувати глобальну конфігурацію devtools з додатками, які працюють на більш старій версії Spring Boot, яка не підтримує розташування $HOME/.config/spring-boot.

Профілі не підтримуються у файлах properties/yaml для devtools.

Будь-які профілі активовані в .spring-boot-devtools.properties , не впливатимуть на завантаження пов'язаних із конкретним профілем файлів. Імена файлів, специфічні для профілів (виду spring-boot-devtools-<profile>.properties), та документи spring.config.activate.on-profile у файлах YAML і Properties не підтримуються.

Конфігурування watcher-а файлової системи

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

Properties
spring.devtools.restart.poll-interval=2s spring.devtools.restart.quiet-period= 1s
Yaml
spring: devtools: restart: poll-interval : "2s" quiet-period: "1s"

Тепер відстежувані каталоги classpath опитуються кожні 2 секунди на предмет змін, а 1-секундний період бездіяльності дотримується, щоб переконатися у відсутності додаткових змін класів.

Віддалені програми

Інструменти розробника 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. Як і будь-який важливий пароль або конфіденційні відомості, значення має бути унікальним і надійним, щоб його не можна було вгадати або підібрати методом перебору. приймаюча з'єднання, і клієнтська програма, яку ви виконуєте у своїй IDE. Серверний компонент автоматично активується, якщо встановлено властивість spring.devtools.remote.secret. Клієнтський компонент потрібно запускати вручну.

Віддалена робота з devtools не підтримується для програм Spring WebFlux.

Виконання віддаленої клієнтської програми

Віддалена клієнтська програма розроблена для виконання з вашої IDE. Необхідно виконати org.springframework.boot.devtools.RemoteSpringApplication з тим же classpath, що й віддалений проект, до якого ви підключаєтеся. Єдиним обов'язковим аргументом програми є віддалена 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 :: (v2.7.5) 2022-10-20 12:40:15.175 INFO 16215 --- [main] /.m2/repository/org/springframework/boot/spring-boot-devtools/2.7.5/spring-boot-devtools-2.7.5.jar started by myuser in /opt/apps/) 2022-10-20 12: 40:15.182 INFO 16215 --- [ main] o.s.b.devtools.RemoteSpringApplication : Немає активного profile set, falling back to 1 default profile: "default" 2022-10-20 12:40:15.913 IN. OptionalLiveReloadServer : LiveReload server є керування на port 35729 2022-10-20 12:40:15.946 INFO 16215 --- [ main] o.s.b.devtools.RemoteSpringApplication : Started RemoteSpring2
Оскільки віддалений клієнт використовує той же classpath, що і фактична програма, він може безпосередньо читати властивості програми. Так зчитується властивість spring.devtools.remote.secret і передається серверу для аутентифікації.
Завжди рекомендується використовувати https :// в якості протоколу підключення, щоб трафік був зашифрований і паролі не можна було перехопити. застосунку, налаштуйте властивості spring.devtools.remote.proxy.host та spring.devtools.remote.proxy.port.

Видалене оновлення

Віддалений клієнт відслідковує зміни в дорозі класів вашої програми так само, як це робить програма локального перезапуску. Будь-який оновлений ресурс передається віддаленому додатку і (якщо потрібно) ініціює перезапуск. Це може бути корисним, якщо ви повторюєте функцію, яка використовує хмарну службу, якої немає на локальному рівні. Як правило, віддалене оновлення та перезавантаження відбуваються набагато швидше, ніж повна перебудова та розгортання.

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

Зазвичай це проявляється у вигляді попередження в журналах RemoteSpringApplication про те, що не вдалося завантажити деякі класи, і подальшої повторної спроби . Але це також може вилитися в неузгодженість коду програми та неможливість перезапуску після завантаження першого пакета змін. Якщо ви спостерігаєте подібні проблеми постійно, спробуйте збільшити параметри spring.devtools.restart.poll-interval та spring.devtools.restart.quiet-period до значень, які відповідають вашому оточенню розробки .

Файли відстежуються лише під час виконання віддаленого клієнта.Якщо ви зміните файл до запуску віддаленого клієнта, він не буде перенесений на віддалений сервер.