Что такое spring boot starter

Создаем свой Spring Boot Starter

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

1 мар. 2023 · 6 минуты на чтение

Один из мощных механизмов Spring Boot — возможность использования «стартеров» для быстрой настройки нового проекта с предварительно сконфигурированными зависимостями.

Стартеры Spring Boot — это, предварительно упакованные наборы зависимостей и сконфигурированных бинов для обеспечения определённой функциональности. Например, доступа к базе данных или безопасности.

Возьмём мою библиотеку GodFather Telegram, которая позволяет создавать ботов для Telegram. Без стартера вам пришлось бы создать бинов 15: бин для принятия входящих событий от телеграма, бин для отправки сообщений, бин для построения сценария бота, множество инфраструктурных бинов. Без подробной документации не обойтись.

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

У клиентов стартера остаётся возможность переопределить внутренние бины, если сценарии использования выходят за рамки дефолтных настроек. Также разработчик стартера может вынести множество настроек в файл application.properties .

В этой статье мы рассмотрим, как создать собственный стартер Spring Boot. Обсудим некоторые лучшие практики и советы по созданию.

Спонсор поста

Создаем свой стартер

Демо проект: Godfather-Bots/telegram-bot-spring-boot-starter

Написание стартера будем рассматривать на примере моей библиотеки для создания ботов GodFather Telegram.

Для начала определимся с groupId и artifactId . Все официальные стартеры придерживаются следующей схемы именования spring-boot-starter-* , где * это конкретный тип приложения.

Сторонние стартеры не должны начинаться с spring-boot, поскольку они зарезервированы для официальных стартеров от разработчиков Spring. Сторонний стартер обычно начинается с названия проекта. Например, мой стартер называется telegram-bot-spring-boot-starter .

Можно реализовать стартер как дополнительный maven-модуль основного проекта, или как отдельный проект. Я предпочитаю делать отдельный проект.

Поэтому создаём пустой SpringBoot проект. Убедитесь, что в pom.xml присутствуют следующие зависимости:

 org.springframework.boot spring-boot-starter  org.springframework.boot spring-boot-configuration-processor true 

Добавьте зависимости вашей библиотеки. В моём случае их три:

 dev.struchkov.godfather.telegram telegram-consumer-simple $ dev.struchkov.godfather.telegram telegram-core-simple $ dev.struchkov.godfather.telegram telegram-sender-simple $ 

Теперь создадим обычный класс конфигурации Spring с нужными бинами.

@Configuration public class TelegramBotAutoconfiguration < @Bean(AUTORESPONDER_EXECUTORS_SERVICE) public ExecutorService executorService( TelegramBotAutoresponderProperty autoresponderProperty ) < return Executors.newFixedThreadPool(autoresponderProperty.getThreads()); >. . . . . @Bean public TelegramService telegramService(TelegramConnect telegramConnect) < return new TelegramServiceImpl(telegramConnect); >>

Смысла описывать всю конфигурацию нет, это просто бины необходимые для работы библиотеки.

Пока это ничем не примечательный модуль с обычным классом конфигурации, что делает его стартером? Стартером его сделает особый файл, создадим его.

В папке resources создаём папку META-INF , в ней папку spring , и в ней файл org.springframework.boot.autoconfigure.AutoConfiguration.imports .

Этот файл должен содержать перечисление конфигураций. В моём случае это одна конфигурация. Каждую конфигурацию указывайте с новой строки.

dev.struchkov.godfather.telegram.starter.config.TelegramBotAutoconfiguration

Spring Boot 3

Если вы используете Spring Boot 2.7 и ниже, то необходимо создать папку META-INF и в ней файл spring.factories .

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

Проперти классы

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

Для этого создайте класс и аннотируйте его @ConfigurationProperties или добавьте существующий через конфигурацию:

@Configuration public class TelegramBotPropertyConfiguration < @Bean @ConfigurationProperties("telegram.bot") public TelegramBotConfig telegramConfig() < return new TelegramBotConfig(); >>

А в pom.xml добавим зависимость, которая генерирует метаданные о классах приложения, аннотированных @ConfigurationProperties .

 org.springframework.boot spring-boot-configuration-processor true 

Этот процессор аннотаций создаст файл META-INF/spring-configuration-metadata.json , который содержит метаданные о параметрах конфигурации в классе TelegramBotConfig . Эти метаданные включают Javadoc о полях, поэтому убедитесь, что Javadoc понятен.

В Idea плагин Spring Assistant будет читать метаданные и обеспечивать подсказки для этих свойств.

Также мы можем добавить некоторые свойства вручную, создав файл META-INF/additional-spring-configuration-metadata.json :

Процессор аннотаций автоматически объединит содержимое этого файла с автоматически созданным файлом.

Conditionals

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

Например, в моем случае нет смысла поднимать бины, если пользователь не указал переменные подключения к боту в application.yml , потому что всё завязано на них.

Для решения этой проблемы существуют аннотации @Conditional.

@ConditionalOnProperty

Воспользуемся аннотацией @ConditionalOnProperty , которая проверяет наличие заполнения конкретной проперти в application.yml .

@Bean @ConfigurationProperties("telegram.bot") @ConditionalOnProperty(prefix = "telegram.bot", name = "token") public TelegramBotConfig telegramConfig()

Бин TelegramBotConfig будет создаваться, только если указана проперти telegram.bot.token .

Используя параметр аннотации value , можно указать конкретные значения проперти. В моем случае важно само наличие токена.

@ConditionalOnBean

Также воспользуемся @ConditionalOnBean , которая создаёт бин, когда в BeanFactory присутствует указанный в @ConditionalOnBean бин.

@Bean @ConditionalOnBean(TelegramBotConfig.class) public TelegramDefaultConnect telegramDefaultConnect(TelegramBotConfig telegramConfig)

@ConditionalOnMissingBean позволяет создавать бин, если указанный бин отсутствует в BeanFactory .

@ConditionalOnClass

Создаёт бин, только если указанный класс есть в classpath . И противоположный ему @ConditionalOnMissingClass .

Рандомный блок

Несколько классов автоконфигурации

При добавлении нескольких классов автоконфигурации и использовании аннотаций @ConditionalOnBean вы столкнётесь с неожиданным поведением — условие не будет отрабатывать и бин не будет создаваться.

Это происходит, потому что Spring берёт конфигурации в произвольном порядке, и может сначала попробовать поднять бин помеченный @ConditionalOnBean , хотя бин в условии будет создан позже. Порядок классов автоконфигураций в файле никак не влияет на порядок создания бинов.

Чтобы этого избежать, используйте аннотации @AutoConfigureAfter или @AutoConfigureBefore над классом конфигурации, которые явно задают порядок создания бинов.

Опциональные бины

Еще одним полезным классом является ObjectProvider , который позволяет передавать необязательные бины. Похоже на логику работы Optional.

@Bean @ConfigurationProperties("telegram.bot") @ConditionalOnProperty(prefix = "telegram.bot", name = "token") public TelegramBotConfig telegramConfig( ObjectProvider proxyConfigProvider ) < final TelegramBotConfig telegramBotConfig = new TelegramBotConfig(); final ProxyConfig proxyConfig = proxyConfigProvider.getIfAvailable(); if (proxyConfig != null) < telegramBotConfig.setProxyConfig(proxyConfig); >return telegramBotConfig; >

Бин ProxyConfig является опциональным. Если его не будет, мы всё равно хотим создать TelegramBotConfig . Если не использовать ObjectProvider , то приложение упадёт при старте, если бина ProxyConfig не будет.

Бины по умолчанию

Мы можем позволить пользователю переопределять наши бины, но предоставлять дефолтные бины. Для этого воспользуемся аннотацией @ConditionalOnMissingBean

@Bean @ConditionalOnMissingBean(PersonSettingRepository.class) public PersonSettingRepository personSettingRepository()

Обратите внимание, что в @ConditionalOnMissingBean мы указываем тот же класс, что и возвращаем. Таким образом, если пользователь стартера определит бин PersonSettingRepository , то дефолтный бин из автоконфигурации не будет создан.

Улучшаем время запуска

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

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

Чтобы метаданные генерировались, нужно добавить процессор аннотаций в стартовый модуль:

 org.springframework.boot spring-boot-autoconfigure-processor true 

Во время сборки метаданные будут сгенерированы в файл META-INF/spring-autoconfigure-metadata.properties , который будет выглядеть так:

dev.struchkov.godfather.telegram.starter.config.TelegramBotAutoconfiguration= dev.struchkov.godfather.telegram.starter.config.TelegramBotAutoconfiguration.AutoConfigureAfter=dev.struchkov.godfather.telegram.starter.config.TelegramBotDataConfiguration dev.struchkov.godfather.telegram.starter.config.TelegramBotAutoconfiguration.ConditionalOnBean=dev.struchkov.godfather.telegram.simple.core.TelegramConnectBot dev.struchkov.godfather.telegram.starter.config.TelegramBotDataConfiguration= dev.struchkov.godfather.telegram.starter.config.TelegramBotDataConfiguration.AutoConfigureAfter=dev.struchkov.godfather.telegram.starter.config.TelegramBotPropertyConfiguration

Использование стартера

Теперь, когда стартер готов, мы можем его добавить в наше другое приложение:

 dev.struchkov.godfather.telegram telegram-bot-spring-boot-starter $ 

Теперь нам доступны все сконфигурированные бины.

Заключение

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

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

Spring Boot Starter — как и зачем?

Spring — уже не магия (спасибо «Spring-потрошителю» и Евгению Борисову), а вот Spring Boot довольно часто клеймят магической поделкой. Но многим нравится, особенно новичкам!

В докладе мы осветим следующее:

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

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

Максим Гореликов

Разработчик из Альфа-Лаборатории, занимается разработкой API для мобильных приложений и немного слоем безопасности. В основном использует экосистему Spring и Netflix, но пробует всё, что найдет хорошего на GitHub. Экспериментирует с реактивными подходами, несколько экспериментов успешно дожили до продакшна. Хочет понимать не только свои приложения, но и всё, что вокруг них, поэтому работает со всей инфраструктурой (логи, CI/CD, оркестрация). В общем, DevOps — наше все.

Кирилл Толкачев

Главный разработчик в Альфа-Лаборатории. Разрабатывает различные банковские API. Формирует принципы и наборы инструментов для работы с микросервисной архитектурой. Большой поклонник Groovy, Gradle, Spring и стека технологий Netflix-а. Постоянный резидент подкаста «Разбор Полётов». Методологию DevOps-а знает не понаслышке и имеет почти двухлетний опыт её применения.

© JUG.ru Group, 2016-2018

Java Blog

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

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

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

Все официальные стартеры следуют аналогичной схеме именования; spring-boot-starter-*, где * это конкретный тип приложения. Эта структура наименования предназначена, чтобы помочь, когда вам нужно найти стартер. Интеграция Maven во многие IDE позволяет вам искать зависимости по имени. Например, если установлен соответствующий плагин Eclipse или STS, вы можете нажать ctrl-space в редакторе POM и набрать «spring-boot-starter» для получения полного списка.

Сторонние стартеры не должны начинаться с spring-boot, поскольку они зарезервированы для официальных артефактов Spring Boot. Скорее, сторонний стартер обычно начинается с названия проекта. Например, сторонний стартер проекта под названием thirdpartyproject обычно будет называться thirdpartyproject-spring-boot-starter.

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

Core starter, включающий поддержку автоконфигурации, логирование и YAML

Starter для JMS обмена сообщениями, используя Apache ActiveMQ

Starter для использования Spring AMQP и Rabbit MQ

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

Starter для JMS обмена сообщениями, используя Apache Artemis

Starter для использования Spring Batch

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

Starter для использования Spring Cloud Connectors которые облегчают подключение к сервисам в облачных платформах, таких как Cloud Foundry и Heroku. Устарело — используйте Java CFEnv

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

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

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

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

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

Starter для использования Spring Data JDBC

Starter для использования Spring Data JPA с Hibernate

Starter для использования Spring Data LDAP

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

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

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

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

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

Starter для представления Spring Data репозиториев через REST, используя Spring Data REST

Starter для использования поисковой платформы Apache Solr с Spring Data Solr

Starter для создания MVC web приложений, используя FreeMarker views

Starter для создания MVC web приложений, используя Groovy Templates views

Starter для создания hypermedia-based RESTful web приложений с Spring MVC и Spring HATEOAS

Starter для использования Spring Integration

Starter для использования JDBC с HikariCP пулом соединений

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

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

Starter для чтения и записи json

Starter для JTA транзакций, используя Atomikos

Starter для JTA транзакций, используя Bitronix

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

Starter для создания web приложений, используя Mustache views

Starter для использования возможностей Spring Security OAuth2/OpenID Connect клиента

Starter для использования возможностей Spring Security OAuth2 ресурс сервера

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

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

Starter для использования Spring Security

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

Starter для создания MVC web приложений, используя Thymeleaf views

Starter для использования Java Bean Validation с Hibernate Validator

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

Starter для использования Spring Web Services

Starter для создания WebFlux приложений, используя Spring Framework& поддержку Reactive Web

Starter для создания WebSocket приложений, используя Spring Framework поддержку WebSocket

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

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

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

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

Starter для использования Log4j2 для логирования. Альтернатива spring-boot-starter-logging

Starter для логирования, используя Logback. Стартер логирования по умолчанию

Starter для использования Reactor Netty в качестве встроенного reactive HTTP сервера.

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

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

• Системы сборки и Spring Boot: использование Maven
• Разработка вашего первого Spring Boot приложения
• Установка Spring Boot: Maven
• Установка Spring Boot: Gradle

Пишем свой spring-boot-starter

Большинство java-разработчиков уже познакомились с проектом Spring Boot, позволяющим быстро написать приложение, использующее различные компоненты Spring Framework (Spring MVC, Spring Data и многие другие).

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

В этой статье мне бы хотелось рассказать о том, как создаются стартеры на примере стартера для Spring-social-vkontakte. Spring Social это один из модулей Spring Framework, используемый для интеграции с социальными сетями. В проект Spring Boot включены стартеры для таких социальных сетей как Facebook (spring-boot-starter-social-facebook), Twitter (spring-boot-starter-social-twitter) и LinkedIn (spring-boot-starter-social-twitter), основанные на использовании соответствующих Social-модулей. Большинство разработчиков из СНГ интересует в первую очередь социальная сеть Вконтакте, для которой существует сторонний модуль spring-social-vkontakte. Соответственно, стартера для этого модуля еще нет. Написанием этого стартера мы и займемся в этой статье.

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

Создадим такой класс для нашего стартера:

@Configuration @ConditionalOnClass() @ConditionalOnProperty(prefix= "ru.shadam.social-vkontakte", name = < "client-id", "client-secret">) @AutoConfigureBefore(SocialWebAutoConfiguration.class) @AutoConfigureAfter(WebMvcAutoConfiguration.class) public class VKontakteAutoConfiguration

Мы используем аннотации, чтобы указать SpringBoot, что наш класс является конфигурацией (@Configuration), аннотации, чтобы задать условия, при которых наш AutoConfiguration будет использоваться для создания бинов, а также аннотации, чтобы указать каково место нашей автоконфигурации в процедуре инициализации приложения.

@ConditionalOnClass() 

означает, что бины будут создаваться при наличии в classpath SocialConfigurerAdapter(входит в модуль Spring-Social) и VKontakteConnectionFactory (входит в модуль Spring-Social-Vkontakte). Таким образом, без нужных для нашего стартера зависимостей бины создаваться не будут.

@ConditionalOnProperty(prefix= "ru.shadam.social-vkontakte", name = < "client-id", "client-secret">) 

означает, что бины будут создаваться только при наличии property ru.shadam.social-vkontakte.client-id и ru.shadam.social-vkontakte.client-secret.

@AutoConfigureBefore(SocialWebAutoConfiguration.class) @AutoConfigureAfter(WebMvcAutoConfiguration.class) 

означает, что наш бин будет инициализироваться после WebMvc и до SocialWeb. Это нужно, чтобы к моменту инициализации SocialWeb наши бины уже были зарегистрированы.

Теперь перейдем к тому, какие бины мы сконфигурируем в нашем AutoConfiguration.

VKontakteAutoConfiguration.java

@Configuration @ConditionalOnClass() @ConditionalOnProperty(prefix= "ru.shadam.social-vkontakte", name = < "client-id", "client-secret">) @AutoConfigureBefore(SocialWebAutoConfiguration.class) @AutoConfigureAfter(WebMvcAutoConfiguration.class) public class VKontakteAutoConfiguration < @Configuration @EnableSocial @EnableConfigurationProperties(VKontakteProperties.class) @ConditionalOnWebApplication protected static class VKontakteConfigurationAdapter extends SocialConfigurerAdapter < @Autowired private VKontakteProperties properties; @Bean @ConditionalOnMissingBean @Scope(value = "request", proxyMode = ScopedProxyMode.INTERFACES) public VKontakte vkontakte(ConnectionRepository repository) < Connectionconnection = repository.findPrimaryConnection(VKontakte.class); if (connection != null) < return connection.getApi(); >return new VKontakteTemplate(this.properties.getClientId(), this.properties.getClientSecret()); > private ConnectionFactory createConnectionFactory() < return new VKontakteConnectionFactory(this.properties.getClientId(), this.properties.getClientSecret()); >@Override public void addConnectionFactories(ConnectionFactoryConfigurer connectionFactoryConfigurer, Environment environment) < connectionFactoryConfigurer.addConnectionFactory(createConnectionFactory()); >> > 

Расширяем SocialConfigurationAdapter, который нужен для того чтобы зарегистрировать нашу ConnectionFactory. Для этого в SocialConfigurerAdapter есть callback-метод:

addConnectionFactories(ConnectionFactoryConfigurer, Environment)

Его мы и переопределим, добавляя нашу ConnectionFactory.

Также зарегистрируем request-scoped бин Vkontakte, которые представляет собой интерфейс для доступа к API Вконтакте. При этом, если пользователь авторизуется через приложение, то операции взаимодействия с API будет выполнено с использованием auth_token.

Рассмотрим также класс VkontakteProperties, который используется для получения конфигурации из properties-файлов приложения

VkontakteProperties.java

@ConfigurationProperties(prefix = "ru.shadam.social-vkontakte") public class VKontakteProperties < private String clientId; private String clientSecret; public String getClientId() < return clientId; >public void setClientId(String clientId) < this.clientId = clientId; >public String getClientSecret() < return clientSecret; >public void setClientSecret(String clientSecret) < this.clientSecret = clientSecret; >> 

За получение значений из properties файлов отвечает аннотация:

@ConfigurationProperties(prefix = "ru.shadam.social-vkontakte") 

Она сообщает SpringBoot, что нужно попытаться все проперти, начинающиеся с префикса ru.shadam.social-vkontakte поместить в соответствующие поля класса.

Последним нашим шагом будет создание файла, позволяющего SpringBoot найти наш AutoConfiguration класс. Для этого существует специальный файл spring.factories, который нужно поместить в META-INF папку получающегося jar-файла.

В этом файле нам надо указать наш AutoConfiguration-класс.

org.springframework.boot.autoconfigure.EnableAutoConfiguration=ru.shadam.spring.boot.vkontakte.VKontakteAutoConfiguration 

Теперь, подключив получившийся jar к нашему Spring Boot проекту и задав в конфигурации ru.shadam.social-vkontakte.client-id и ru.shadam.social-vkontakte.client-secret, мы получим в нашем приложении сконфигруированные пути /connect/vkontakte и бин Vkontakte, который мы можем использовать для доступа к API Вконтакте.

1. docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html
2. Ссылка на проект на github: github.com/saladinkzn/social-vkontakte-spring-boot-starter