( Примечание редактора : При ~ 3750 словах вы, вероятно, не захотите пытаться читать это на мобильном устройстве. Добавьте его в закладки и вернитесь позже.)
Вступление
Похоже, что все и их бабушка используют Spring Boot для создания проектов. Но очень немногие могут ответить на вопрос: “Что такое Spring Boot?”
Краткий ответ :
Веб-сайт Spring Boot предлагает следующий ответ: “Spring Boot использует самоуверенный взгляд на платформу Spring и сторонние библиотеки, чтобы вы могли начать работу с минимальной суетой”.
Вау, это совсем не помогает, не так ли?
К счастью, есть также длинный ответ :
Остальная часть этой статьи.
Небольшое предостережение
Я могу дать вам гарантию на 99,99%, что вы скорее захотите прочитать Что такое Spring Framework? статья первая, если…:
…вы совершенно новичок в Spring Boot (или Java).
…вы думаете, что “Spring Framework, Spring Web MVC и Spring Boot – это одно и то же”.
…вы думаете: “Прекрати все это прочее дерьмо, я просто хочу узнать о Spring Boot!”.
(Особенно если вы думаете: “прекрати все это прочее дерьмо”).
Найдите время, чтобы сначала закончить предыдущую статью, а затем вернитесь сюда.
Кроме того, если вы ищете несколько простых руководств по копированию и вставке Spring Boot REST/microservice, я бы посоветовал вам перейти по адресу https://spring.io/guides вместо этого.
Цели этой статьи
Чтобы дать вам глубокое представление о Spring Boot и его автоматических конфигурациях.
Чтобы показать вам, как Spring Boot автоматически загружает Tomcat всякий раз, когда вы запускаете метод main().
Чтобы показать вам, как работает магия свойств Spring Boot. Вы указываете пару свойств и внезапно получаете рабочий доступ к базе данных.
Давайте начнем.
Основы весенних ботинок: Условные обозначения
Прежде чем вы станете гуру Spring Boot, вам нужно понять только одну очень важную концепцию: аннотацию @Conditional Spring framework.
Родительский совет : Не пропускайте этот раздел, так как он является основой для всего , что делает Spring Boot. Кроме того, я сделаю это как можно более интересным.
Как совместно использовать конфигурации контекста приложения?
Представьте, что вы работаете в ReallyBigCompany ™ с парой команд, работающих над различными проектами или продуктами Spring. Но ты не используя Spring Boot, просто обычный Spring framework.
Также представьте, что в какой-то момент у одного из ваших разработчиков возникла отличная идея извлечь одну общую ApplicationContextConfiguration из всех проектов, потому что он заметил, что в каждом проекте компании используется несколько одинаковых компонентов.
@Configuration
public class ReallyBigCompanySharedContextConfiguration {
@Bean
public ReallyBigCompanyProprietaryFlywayClone flywayClone() {
return new ReallyBigCompanyProprietaryFlywayClone();
}
}
Эта конфигурация общего контекста будет жить в собственном проекте, который в конечном итоге будет опубликован как собственный файл .jar, который все проекты Spring вашей компании могут импортировать как зависимость Maven/Gradle.
Представьте, что действительно крупная компания создала собственный клон Flyway, то есть нечто, что инициализирует базы данных и управляет ими. И поскольку каждый проект в вашей компании использует реляционную базу данных, имеет смысл извлечь ее в эту общую конфигурацию.
Затем ваши фактические конфигурации контекста приложения проекта будут выполнять это:
@Configuration
@Import(ReallyBigCompanySharedConfiguration.class)
public class EarlyExitUnicornProjectContextConfiguration {
}
С этого момента каждый проект компании импортирует общую конфигурацию, поскольку она содержит так много полезных функций (ну, на данный момент только клон Flyway, но вы поняли суть).
Вы бы указали здесь свои компоненты, относящиеся к конкретному проекту, как обычно.
В чем проблема с общей конфигурацией Applicationcontext?
Наличие такой общей конфигурации Spring в вашей компании работает, но на горизонте возникает проблема.
Что делать, если вы хотите создать другой проект, который хочет импортировать эту общую конфигурацию, но не имеет reallybigcompanyprietaryflywayclone, потому что он не использует реляционную базу данных?
Тогда вам нужен способ сообщить Spring: Что @Configuration в порядке, но, пожалуйста, не создавайте этот конкретный @Bean – просто игнорируйте его. Продолжайте и создайте все остальные @Beans, хотя.
Это именно для чего предназначена @Conditional аннотация Spring.
Что такое @Conditional аннотация Spring?
Spring framework , начиная с версии 4.0 с 2015 года, предлагает аннотацию @Conditional. Вы можете поместить его в @Bean methods, @Components или даже @Configuration, и это выглядит так:
@Conditional(SomeCondition.class)
- У него есть параметр класса “Condition”, который представляет собой класс, имеющий метод с именем “matches”, возвращающий простое логическое значение.
- True: (Further Evaluate/Register) Create that @Bean, @Component or @Configuration - False: (Stop Evaluating/Registering) Don't create that @Bean, @Component or @Configuration
Короче говоря: несмотря на то, что конфигурация контекста приложения поставляется с определенными определениями @Bean, вы как конечный пользователь все равно можете в некоторой степени повлиять на то, будет ли создан компонент или нет.
Создание общей конфигурации ApplicationContext @Conditional
Что это означает для нашей общей конфигурации? Мы могли бы реорганизовать его так, чтобы он выглядел следующим образом:
@Configuration
public class ReallyBigCompanySharedContextConfiguration {
@Bean
@Conditional(IsRelationalDatabaseCondition.class)
public ReallyBigCompanyProprietaryFlywayClone flywayClone() {
return new ReallyBigCompanyProprietaryFlywayClone();
}
}
- Это точно такая же конфигурация контекста, как и раньше, только теперь ваш метод @Bean также помечен условием, которое нам еще предстоит написать.
Как может выглядеть это состояние?
Реализация условия пружины
package com.marcobehler;
import org.springframework.context.annotation.Condition;
import org.springframework.context.annotation.ConditionContext;
import org.springframework.core.type.AnnotatedTypeMetadata;
public class IsRelationalDatabaseCondition implements Condition {
@Override
public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
return oracleJdbcDriverOnClassPath() && databaseUrlSet(context);
}
private boolean databaseUrlSet(ConditionContext context) {
return context.getEnvironment().containsProperty("spring.datasource.url");
}
private boolean oracleJdbcDriverOnClassPath() {
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
return true;
} catch (ClassNotFoundException e) {
return false;
}
}
}
Условие – это интерфейс, который предоставляет один метод под названием “matches”, который возвращает true/false: Выполнено условие или нет.
Я смешиваю здесь два условия: я хочу проверить, находится ли класс oracledriver на пути к классу. И я хочу проверить, установил ли пользователь URL-адрес базы данных в файле .properties.
Проверка свойства довольно проста, так как вы можете пройти через класс среды Spring, который, в свою очередь, проверит все @PropertySources (например: application.properties) на наличие свойства.
Проверка на наличие зависимостей также довольно проста: вы можете проверить доступность определенного класса в вашем пути к классу, и если он там есть, то вы можете предположить, что там есть вся библиотека.
Хотя в реальном мире вы, скорее всего, разделили бы этот класс на два разных условия, в нем выделяются два очень важных условия:
Вы можете создать @Beans в зависимости от конкретных доступных свойств .
Вы можете создать @Beans в зависимости от конкретных библиотек в вашем пути к классу .
Перерыв в перерыве: Что такое Весенняя загрузка?
Несмотря на то, что мы еще не рассмотрели исходный код Spring Boot, сейчас вырисовывается новое понимание.
Что, если Spring Boot – это просто конфигурация общего контекста с множеством @Conditionals?
Условия, которые создают для вас источник данных, потому что вы установили определенные свойства (например: spring.datasource.url)? Или @Conditionals, которые загружают встроенный Tomcat для вас, потому что у вас есть библиотеки Tomcat в вашем classpath?
Да, это (и почти только это) точно что такое Пружинный ботинок. Не веришь мне? Давайте посмотрим на какой-нибудь код.
Пружинный ботинок: Автоконфигурация
Что происходит, когда вы запускаете приложение Spring Boot?
Каждый, кто создал новое приложение Spring Boot, знает, что в конечном итоге вы получите запускаемый метод main(), который запускает волшебство Spring Boot.
package com.example;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class MySpringBootApp {
public static void main(String[] args) {
SpringApplication.run(MySpringBootApp.class, args);
}
}
- Вы запускаете этот основной метод, и внезапно ваш Tomcat загружается, ваш файл application.properties считывается, и вы можете немедленно начать писать @RestControllers.
Как это работает?
Пружинный Ботинок: Три Внутренних Основных Элемента
При запуске вашего приложения Spring происходит много событий, но давайте рассмотрим три конкретных, которые на первый взгляд не имеют много общего, но вместе составляют большую часть основы Spring Boot.
1. Автоматически зарегистрированный @PropertySources
Вы можете указать любому обычному приложению Spring framework читать файлы .properties практически из любого места, которое вы хотите, с помощью аннотации @PropertySource.
@PropertySource(value = "classpath:application.properties", ignoreResourceNotFound = true)
Когда вы запускаете основной метод своего приложения My Spring Boot, Spring Boot автоматически зарегистрирует для вас 17 из этих PropertySources (даже если это неверно, вы можете думать об этом как о 17 из этих аннотаций, автоматически добавляемых в ваш проект).
Вы можете найти полный список источников свойств по умолчанию в официальной документации , но вот выдержка:
4. Command line arguments. ... 10. OS environment variables. ... 15. Application properties packaged inside your jar (application.properties and YAML variants).
Итак, Spring Boot просто имеет набор местоположений свойств по умолчанию, которые он всегда пытается прочитать, например аргументы командной строки или application.properties внутри вашего файла .jar и т.д. Или же он игнорирует местоположение. Это оно.
Итак, что он делает с этими свойствами? Прежде чем мы рассмотрим это в исходном коде Spring Boot, давайте рассмотрим вторую важную вещь, которая происходит при запуске основного метода Spring Boot.
2. Чтение в META-INF/spring.factories
Каждый проект Spring Boot имеет зависимость от следующей библиотеки: org.springframework.boot:spring-boot-автоконфигурация . Это простой файл .jar, содержащий довольно много вся магия весеннего ботинка.
Кроме того, он поставляется с файлом spring.factories, находящимся в папке META-INF.
Когда вы открываете этот файл, там есть один раздел под названием “#Автоконфигурация”, который занимает более ста строк.
# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\
org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration,\
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,\
org.springframework.boot.autoconfigure.cloud.CloudServiceConnectorsAutoConfiguration,\
org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfiguration,\
org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfiguration,\
org.springframework.boot.autoconfigure.couchbase.CouchbaseAutoConfiguration,\
org.springframework.boot.autoconfigure.dao.PersistenceExceptionTranslationAutoConfiguration,\
// 100+ more lines
Эти автоматические конфигурации (подробнее об этом через секунду) являются обычными конфигурациями Spring @ с множеством @Conditionals, которые Spring Boot считывает и пытается оценить при каждом запуске приложения.
Но прежде чем мы рассмотрим эти автоматические конфигурации, давайте в последний раз взглянем на одну дополнительную функцию Spring Boot.
3. Усиленная Условная Поддержка
Несколькими абзацами ранее мы видели, что Spring framework поставляется с аннотацией @Conditional. Но эта аннотация немного низкоуровневая.
Spring Boot поставляется со своим собственным набором дополнительных аннотаций @Conditional, которые облегчают жизнь разработчикам. (Обратите внимание, что следующие значения параметров аннотаций @Conditional являются лишь примером)
@ConditionalOnBean(DataSource.class ) . Условие имеет значение true, только если пользователь указал источник данных @Bean в @Configuration.
@ConditionalOnClass(DataSource.class ) . Условие равно true, если класс источника данных находится на пути к классу.
@@ConditionalOnCloudPlatform(облачная платформа. Героку) . Условие выполняется, если для облачной платформы установлено значение Heroku.
@@conditionalonexpression(“someSpELExpression) . Условие равно true, если выражение SpEL равно true.
@@ConditionalOnJava(javaversion. ВОСЕМЬ) . Условие равно true, если текущая версия Java равна 8.
@@Conditionalnode(“java:comp/env/ejb/myejb”) . Условие имеет значение true, если указанный контекст JNDI существует.
@ConditionalOnMissingBean(DataSource.class ) . Условие равно true, если пользователь не указал источник данных @Bean в любом @Configuration.
@ConditionalOnMissingКласс(DataSource.class ) . Условие равно true, если класс источника данных находится не на пути к классу.
@@Conditionalonwebapplication . Условие равно true, если приложение является веб-приложением.
@ConditionalOnProperty(“my.property”) . Условие равно true, если задано значение my.property.
@@Conditionaldatasource(“путь к классу:my.properties”) . Условие истинно, если my.properties существует.
@ConditionalOnSingleCandidate(DataSource.class ) . Совпадает, если в вашем приложении указан один компонент primary DataSource.
@ConditionalOnWebApplication . Условие равно true, если приложение не является веб-приложением.
Итак, вкратце, с Spring Boot вам не нужно самостоятельно писать наиболее распространенные условия (например, проверять наличие свойства). Вместо этого вы можете использовать его расширенные аннотации @Conditional.
Резюме
Когда весенний ботинок загружается:
Он пытается прочитать in .properties из 17 жестко закодированных местоположений.
Он также считывает файл spring.factories вашего модуля autoconfigureи определяет, какие автоматические конфигурации он должен оценивать.
Он имеет расширенную концепцию @Conditionals по сравнению с обычной Spring. Это пригодится через секунду.
Этого достаточно, чтобы начать анализировать указанную автоматическую конфигурацию.
Где взять исходный код Spring Boot
Чтобы продолжить, вы можете самостоятельно ознакомиться с проектом Spring Boot. Не волнуйтесь, это просто быстрый “git clone” и импорт проекта.
Также обратите внимание, что Spring Boot эффективно переключился на Gradle как систему сборки в главной ветви, в то время как более старые ветви выпуска по-прежнему основаны на Maven.
git clone https://github.com/spring-projects/spring-boot.git
Как проанализировать автоконфигурацию: DataSourceAutoConfiguration
Внутри модуля spring-boot-autoconfigureвы найдете подпакет и автоконфигурацию для каждой Spring или сторонней библиотеки, с которой интегрируется Spring Boot.
Давайте сначала взглянем на класс DataSourceAutoConfiguration. Именно он создает для вас источник данных после того, как вы добавите пару свойств, таких как “spring.datasource.url”, в один из ваших файлов .properties.
Вухаа, посмотрите на этот фестиваль аннотаций! Давайте пройдемся по нему построчно.
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
@EnableConfigurationProperties(DataSourceProperties.class)
@Import({ DataSourcePoolMetadataProvidersConfiguration.class, DataSourceInitializationConfiguration.class })
public class DataSourceAutoConfiguration {
@Configuration(proxyBeanMethods = false)
@Conditional(EmbeddedDatabaseCondition.class)
@ConditionalOnMissingBean({ DataSource.class, XADataSource.class })
@Import(EmbeddedDataSourceConfiguration.class)
protected static class EmbeddedDatabaseConfiguration {
}
@Configuration(proxyBeanMethods = false)
@Conditional(PooledDataSourceCondition.class)
@ConditionalOnMissingBean({ DataSource.class, XADataSource.class })
@Import({ DataSourceConfiguration.Hikari.class, DataSourceConfiguration.Tomcat.class,
DataSourceConfiguration.Dbcp2.class, DataSourceConfiguration.Generic.class,
DataSourceJmxConfiguration.class })
protected static class PooledDataSourceConfiguration {
}
// some more
}
DataSourceAutoConfiguration – это обычная конфигурация Spring @.
Для дальнейшей оценки @Configuration вам необходимо иметь два класса на пути к классу. Источник данных и тип EmbeddedDatabaseType. Если бы это условие было ложным, вся @Configuration не была бы оценена.
Пока мы можем игнорировать эти две строки, но в качестве краткого примечания: @EnableConfigurationProperties позволяет автоматически устанавливать/преобразовывать свойства, которые вы помещаете в свои файлы .properties, в объект, например, datasourceproperties здесь.
DataSourceAutoConfiguration имеет две другие, внутренние @конфигурации. Одним из них является конфигурация объединенного источника данных, которая (условно) создаст для вас источник данных пула подключений.
У него есть @Condition для условия PooledDataSource, которое на самом деле является вложенным @ConditionalOnProperty. Ай!
Конфигурация объединенного источника данных подвергается дальнейшей оценке только в том случае, если пользователь (т.Е. Вы) еще не указал Источник данных или сам XADataSource.
Конфигурация объединенного источника данных импортирует довольно много других конфигураций, если быть более точным, по одной конфигурации для каждой поддерживаемой библиотеки пула подключений (Hikari, Tomcat, Dbcp2 и т.д.).
Это многое нужно переварить, но, по сути, это обычные конфигурации Spring @, защищенные @Conditionals. В довершение всего, давайте взглянем на импортированную конфигурацию DataSourceConfiguration.Hikari.class .
Еще больше аннотаций!
/**
* Hikari DataSource configuration.
*/
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(HikariDataSource.class)
@ConditionalOnMissingBean(DataSource.class)
@ConditionalOnProperty(name = "spring.datasource.type", havingValue = "com.zaxxer.hikari.HikariDataSource",
matchIfMissing = true)
static class Hikari {
@Bean
@ConfigurationProperties(prefix = "spring.datasource.hikari")
HikariDataSource dataSource(DataSourceProperties properties) {
HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class);
if (StringUtils.hasText(properties.getName())) {
dataSource.setPoolName(properties.getName());
}
return dataSource;
}
}
Еще одна обычная конфигурация Spring @.
В HikariDataSource.class должен быть на пути к классу, т.е. hikaricp должен быть добавлен в ваш файл pom.xml/build.gradle.
Пользователь должен не сам указывать компонент источника данных.
Либо свойство “spring.datasource.type” отсутствует, либо оно должно иметь определенное значение “com.zaxxer.hikari. Источник хикаридатас”.
Если все эти условия совпадают, то создается старый добрый Spring @Bean. Источник данных HikariDataSource. Это то, что в противном случае вам пришлось бы создать самостоятельно, просмотрев документацию Hikaricp.
Итак, по сути, все, что делает DataSourceAutoConfiguration, – это проверяет наличие сторонних зависимостей на пути к классу и пару свойств, которые необходимо установить. Затем он загружает для вас источник данных, который в противном случае вам пришлось бы настраивать самостоятельно вручную.
Или проще говоря: если у вас есть HikariCP на вашем пути к классу, то вы автоматически создаете HikariDataSource @Bean. Если бы у вас была библиотека DBCP2 на вашем пути к классу (и исключена Hikari), то вы бы получили другой пул подключений. Просто переключая зависимости.
Это @Условные полномочия.
Упражнение: Проанализируйте автоконфигурацию Tomcat
Возвращаясь к вопросу с самого начала: как Spring Boot может загрузить встроенный Tomcat по умолчанию? Простой:
Ему необходимо проверить, находится ли Tomcat на пути к классу. (@ConditionalOnClass(Tomcat.class ))
Это может учитывать определенные свойства, которые задает пользователь, например server.port.
Ему необходимо взять Spring Webmvc DispatcherServlet и зарегистрировать его в Tomcat, чтобы заставить ваш @Restcontroller с их @Getmappings и @Postmappings работать.
Он должен запустить ваш встроенный Tomcat (и, следовательно, ваш DispatcherServlet).
Упражнение для вас состоит в том, чтобы найти и понять эти автоконфигурации, специфичные для сервлетов, с соответствующими условными обозначениями.
Подсказка: Взгляните на Dispatcherservletautoconfiguration, а также на EmbeddedWebServerFactoryCustomizerAutoConfiguration.
И если вы закончили с этим, вы можете взглянуть на автоматическую настройку для одной из ваших любимых библиотек, таких как Flyway, Jackson или MongoDB.
Окончательный ответ: Что такое Spring Boot?
Spring Boot – это “всего лишь” пара классов автоматической настройки (Spring @Configuration), которые создают @Beans для вас, если выполняются определенные @условия.
Тремя наиболее важными условиями являются
@ConditionalOnClass . Проверка на наличие зависимостей или, скорее, определенных классов зависимостей (например, Tomcat, HikariCP и т.д.).
@ConditionalOnProperty . Не требует пояснений.
@ConditionalOnMissingBean . Если пользователь уже указал свой собственный, например, источник данных, то Spring Boot не будет пытаться создать свой автоконфигурированный источник.
Вот что подразумевается под “самоуверенными значениями по умолчанию” на домашней странице Spring Boot.
Пружинный ботинок: Зависимости
Не хватает последнего кусочка головоломки. Как все эти зависимости попадают в classpath в проектах Spring Boot? И почему вам не нужно указывать какие-либо номера версий для ваших сторонних библиотек?
Анализ spring-boot-starter-web
Единственная зависимость, которую включает в себя каждый веб-проект Spring Boot, – это зависимость spring-boot-starter-web. Его pom.xml файл выглядит следующим образом:
org.springframework.boot spring-boot-starter-tomcat org.springframework spring-webmvc
Среди других зависимостей зависимость spring-boot-starter-tomcat подключается транзитивно зависимостью starter-web.
Кроме того, Spring WebMVC, веб-фреймворк Spring, подключается транзитивно.
Теперь, когда pom.xml файл для spring-boot-starter-tomcat выглядит следующим образом:
org.apache.tomcat.embed tomcat-embed-core org.apache.tomcat tomcat-annotations-api
- Эта зависимость – это все, что вам нужно для запуска/запуска встроенного Tomcat. Пружинный ботинок втягивает его внутрь, и угадайте, что это значит. Что по умолчанию @ConditionalOnClass(Tomcat.class ) условия будут соблюдены! И это именно то условие, которое Spring Boot оценивает для запуска встроенного Tomcat. Уже не так много ракетостроения, не так ли?
В общем, просмотрев starters, вы обнаружите, что spring-boot-starter-web по умолчанию загружает в ваш проект более 60 других зависимостей и сторонних библиотек. От библиотек JSON и YAML до ведения журнала и веб-фреймворка Spring MVC. Это все базовое управление зависимостями Maven/Gradle.
Почему вы можете удалить версии зависимостей в Spring Boot?
Это оставляет нас с последним вопросом. Почему вам не (скорее: почти никогда) не нужно указывать сторонние версии зависимостей при включении их в ваш pom.xml файл. Итак, вместо этого:
org.hibernate hibernate-core 5.4.12.Final
Вы бы сделали это в проектах Spring Boot.
org.hibernate hibernate-core
Это связано с тем, что проект Spring Boot, созданный исходным zr Spring, расширяется из родительского проекта, называемого spring-boot-dependencies. Это не столько проект, сколько простой pom.xml файл.
И в этом pom.xml файл, у вас есть огромный раздел dependencyManagement (охватывающий каждую стороннюю библиотеку, с которой интегрируется Spring Boot), который определяет зависимости, которые вы можете включить в свой pom.xml файл, без указания номера версии. Потому что он уже указан в этом родительском pom.xml .
5.4.12.Final org.hibernate hibernate-c3p0 ${hibernate.version} org.hibernate hibernate-core ${hibernate.version} org.hibernate hibernate-ehcache ${hibernate.version} org.hibernate hibernate-entitymanager ${hibernate.version} org.hibernate hibernate-envers ${hibernate.version} org.hibernate hibernate-hikaricp ${hibernate.version}
Spring Boot помещает номера версий в раздел <свойства>, чтобы вы могли легко переопределить эти номера версий в своем подпроекте.
Блок – это стандартная функция Maven для определения версий зависимостей “глобально” во всех модулях вашего проекта.
Это pom.xml файл – это причина, по которой вам больше не нужно указывать версии сторонних библиотек. Если, конечно, ваша конкретная сторонняя библиотека не находится в этом pom.xml файл. Тогда вам все равно нужно определить версию самостоятельно.
(Примечание: Наследование от spring-boot-dependencies – это один из способов заставить работать управление зависимостями Spring Boot, другим способом было бы импортировать спецификацию, но я не буду показывать это здесь.)
Управление зависимостями: Резюме
Стартеры, такие как spring-boot-starter-web, включают тонну сторонних библиотек в ваш проект – по умолчанию. Его автоматические конфигурации используют эти зависимости (помните: @ConditionalOnClass) для автоматической настройки и предварительной настройки этих библиотек.
Зависимости от spring-boot-зависимостей pom.xml содержит каждую стороннюю библиотеку (и версию), известную Spring Boot. Эти библиотеки предопределены в разделе управления зависимостями, поэтому вам больше не нужно указывать номера версий в вашем собственном проекте.
часто задаваемые вопросы
Какова последняя версия Spring Boot?
Текущая стабильная версия Spring Boot – 2.2.5. Вы всегда можете ознакомиться с анонсами новых релизов здесь https://github.com/spring-projects/spring-boot/releases .
Как я могу исключить конкретную автоматическую конфигурацию?
Допустим, вы не хотели, чтобы Spring Boot выполнял свою DataSourceAutoConfiguration, вы могли бы отключить ее несколькими способами:
@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class)
public class Application {
public static void main(String[] args) {
SpringApplication.run(PayPalApplication.class, args);
}
}
или
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
Хотя это означает, что вам нужно примерно знать, какая автоматическая конфигурация отвечает за создание каких @Beans, которые вы в конечном итоге узнаете в исходном коде Spring Boot.
Каков наилучший способ создать новый проект Spring Boot?
На самом деле есть только один способ: Spring Initializr, доступный по адресу https://start.spring.io/ . IDE, такие как IntelliJ также используют Initialize для создания новых проектов Spring Boot для вас, абстрагированных под приятным графическим интерфейсом.
Каковы лучшие документы для Spring Boot?
Ха, этот вопрос был ловушкой. Существует, конечно, официальная документация Spring Boot . Но к настоящему времени вы должны понимать, что Spring Boot на самом деле только предварительно настраивает другие библиотеки для вас.
Итак, для написания @Restcontroller вам все равно нужно посмотреть официальную документацию Spring Web MVC . Для Flyway, документация Flyway . Для Couchbase документация Couchbase .
И ТОГДА вам также необходимо знать свойства, которые Spring Boot использует для настройки этих библиотек. Полный список вы можете найти здесь: Общие свойства приложения . Да, это очень длинный список.
Как мне выполнить ведение журнала с помощью Spring Boot?
На самом деле вы не входите в систему с помощью Spring Boot. Вы делаете это с помощью Logback или Log4j2 . Или какая-либо другая поддерживаемая сторонняя библиотека ведения журнала.
Следовательно, вам нужно сначала разобраться в этих библиотеках | .
Затем вам нужно понять, что Spring Boot добавляет поверх этих библиотек, чтобы упростить их использование. (как и тот logback-spring.xml файл и дополнительные поддерживаемые функции). Смотрите официальную документацию .
Как мне выполнить безопасность или Oauth2 с помощью Spring Boot?
Опять же, вы не делаете этого с помощью Spring Boot. Вы делаете это с помощью Spring Security , который хорошо настраивается при загрузке Spring.
Предостережение: вам понадобится добрая пара недель, чтобы полностью понять Spring Security (или вам повезет, если ваши скопированные фрагменты кода из Stackoverflow чудесным образом сработают).
В чем разница между пружиной и пружинным ботинком?
Spring, как и в Spring framework , представляет собой набор инструментов, которые помогут вам быстрее создавать Java-приложения (надеюсь).
Прочитав эту статью, вы должны понять, что Spring Boot просто предварительно настроил эти инструменты для вас с разумными настройками (т.Е. Давайте всегда будем читать в файле classpath:application.properties и использовать свойство server.port для предварительной настройки Tomcat на определенный порт). Следовательно, Spring Boot строит поверх Spring framework.
Однако все становится запутанным, поскольку нынешний маркетинговый ход заключается в том, чтобы называть все Spring Boot или Spring framework просто “Spring”.
В чем разница между Spring WebMVC и Spring Boot?
Опять же, Spring Boot использует Spring WebMVC под капотом. Ваши службы Spring Boot Rest, т.Е. @RestControllers или @Controllers, являются обычными старыми контроллерами Spring WebMVC.
Разницы нет, Spring Boot строит поверх Spring WebMVC.
Плавник
Надеюсь, эта статья прольет некоторый свет на то, что такое Spring Boot. Некоторые заключительные мысли:
Когда дело доходит до создания приложений Spring Boot, вы можете примерно пойти двумя путями:
Рекурсивно копируйте и вставляйте свой путь через ваши проекты Spring Boot с помощью Stackoverflow или Baeldung .
Попытайтесь понять что вы делаете. Это начинается с понимания Пружинный каркас . Затем понимание сторонних библиотек (таких как Log4j2 или Flyway). Затем понимание того, что Spring Boot делает со всеми этими маленькими кусочками и кусочками.
Спасибо за чтение.
Оригинал: “https://dev.to/marcobehler/what-is-spring-boot-autoconfigurations-in-depth-1c3”