spring boot что это такое

Создание приложений с Spring Boot

Этот урок показывает пример того, как Spring Boot помогает вам ускорить и облегчить разработку приложений. Из учебных материалов вы увидите случаи использования Spring Boot. Если вы хотите создать проект на его основе, то посетите Spring Initializr, заполните онформацию о проекте, выберите опции и вы сможете загрузить файл сборки Maven, либо Gradle, либо как проект в виде zip-файла.

Что вы создадите

Вы создадите простое web-приложение с Spring Boot и добавите в него несколько полезных сервисов.

Что вам потребуется

Как проходить этот урок

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

Чтобы начать с нуля, перейдите в Настройка проекта.

Настройка проекта

Для начала вам необходимо настроить базовый скрипт сборки. Вы можете использовать любую систему сборки, которая вам нравится для сборки проетов Spring, но в этом уроке рассмотрим код для работы с Gradle и Maven. Если вы не знакомы ни с одним из них, ознакомьтесь с соответсвующими уроками Сборка Java-проекта с использованием Gradle или Сборка Java-проекта с использованием Maven.

Создание структуры каталогов

Создание файла сборки Gradle

Ниже представлен начальный файл сборки Gradle. Файл pom.xml находится здесь. Если вы используете Spring Tool Suite (STS), то можете импортировать урок прямо из него.

Spring Boot gradle plugin предоставляет множество удобных возможностей:

Узнайте, что вы можете делать с Spring Boot

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

Это лишь несколько примеров, которые предоставляет автоманическая настройка Spring Boot. В то же время, Spring Boot не заработает с вашими настройками. Например, если Thymeleaf в вашем classpath, то Spring Boot добавит SpringTemplateEngine в ваш контекст приложения автоматически. Но если вы определите свой собственный SpringTemplateEngine с вашими настройками, то Spring Boot не добавит его. Это останется под вашим контролем и потребует от вас немного усилий.

Создание простого web приложения

Теперь вы можете создать web контроллер для простого web приложения.

Создание Application класса

Здесь вы создаете Application класс с компонентами:

Метод main() используется Spring Boot методом SpringApplication.run() для запуска приложения. Вы обратили внимание, что нет ни одной строчки на XML? Файла web.xml нет вообще. Это приложение на 100% из чистой Java и вы ничего не делали для настройки какого-либо инструмента или инфраструктуры.

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

Запуск приложения

Для запуска приложения выполните:

Если вы используете Maven, то:

Вы должны увидеть примерно такое:

Добавление сервисов бизнес-уровня

Если вы создаете web-сайт для вашего бизнеса, то вам скорее всего необходимо добавить некоторые сервисы для управления. Spring Boot предоставляет несколько таких «из коробки» в одном из своих модулей, таких как состояние, аудит, бины и другие.

Добавьте это в список зависимостей вашего файла сборки:

Если вы используете Maven, то добавьте это в список зависимостей:

Затем перезапустите приложение:

Если вы используете Maven, то:

Вы увидите новый набор RESTful точек выхода, добавленных в приложение. Это сервисы управления, предоставленные Spring Boot:

это легко проверить по состоянию приложения:

Вы можете попытаться вызвать завершение работы через curl:

Т.к. мы не включили его, запрос блокирован, потому что его не существует.

Просмотр Spring Boot starters

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

ко всему прочему, Spring Boot поддерживает Groovy, позволяя вам создавать Spring MVC приложения в небольшом и единственном файле.

Создайте новый файл app.groovy и поместите в него приведенный ниже код:

Давайте проверим, что получилось:

Spring Boot динамически добавляет аннотации к вашему коду и использует Groovy Grape для подтягивания необходимых для запуска приложения библиотек. Смотрите документацию, если хотите копнуть шлубже.

Поздравляем! Вы только что создали простое web приложени с использованием Spring Boot и изучили как нарастить ваш темп разработки. вы также настроили некоторые удобные сервисы. Это только малая часть того, что может делать Spring Boot.

Источник

Обратная сторона Spring

Неделя Spring на Хабре, судя по всему, открыта. Хочется сказать спасибо переводчику и комментаторам статьи «Почему я ненавижу Spring», которая не смотря на сильный негативный посыл в названии вызвала ряд интересных дискуссий, а так же тем, кто отреагировал на мою прошлую статью Как писать на Spring в 2017. Во многом благодаря комментариям к прошлой статье и появилась эта.

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

В комментариях к предыдущей статье несколько человек очень справедливо указали, что пример Hello World-а на Spring все же не очень показателен. Spring, особенно с использованием Spring Boot, дает ощущение простоты и всемогущества, но непонимание основ и внутренностей фреймворка ведет к большой опасности получить стектрейсом по логу. Что ж, чтобы немного развеять ощущение полной магии происходящего, сегодня мы возьмем приложение из предыдущей статьи и разберем, как и что происходит внутри фреймворка и от каких проблем нас отгораживает Boot. Целевая аудитория все же начинающие разработчики, но с некоторым опытом и базовыми знаниями Java и Spring. Хотя, возможно, и опытным пользователям Spring будет интересно освежить знания того, что происходит под капотом.

Ключевые понятия

Начнем срывать покровы с самых базовых понятий Spring. Бин (bean) — это не что иное, как самый обычный объект. Разница лишь в том, что бинами принято называть те объекты, которые управляются Spring-ом и живут внутри его DI-контейнера. Бином является почти все в Spring — сервисы, контроллеры, репозитории, по сути все приложение состоит из набора бинов. Их можно регистрировать, получать в качестве зависимостей, проксировать, мокать и т.п.

DI контейнер

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

Еще один очень важный момент, который многие упускают при обсуждении DI контейнера, это то, что использование инъекции зависимостей не подразумевает создания интерфейсов для каждого компонента. Это очень простая мысль, но я много раз видел, что из-за своей простоты она не всегда очевидна. Более того, создание интерфейса, если у него лишь одна реализация — считается плохой практикой. Т.е. классы вполне могут сами по себе быть объектами DI. Более того, отсутствие интерфейса даже не мешает их мокать в тестах, т.к. Mockito, например, вполне умеет мокать классы.

Контекст

Конфигурация

Итак, если приложение — это набор бинов, чтобы оно заработало нам нужно этот набор описать.

Конфигурация — это просто описание доступных бинов. Spring дает несколько вариантов, как можно описать набор бинов, которые сформируют приложение. Исторический вариант — это через набор xml файлов. В наши дни ему на смену пришли Java аннотации. Spring Boot построен на аннтациях чуть более, чем полностью и большинство современных библиотек в принципе тоже можно сконфигурить через аннотации. В третьем своем поколении, конфигурация бинов пришла к подходу функциональной регистрации (functional bean registration), которая станет одной из важных новых фич готовящегося к выходу Spring 5.

Типичный класс конфигурации может, выглядеть, например так:

Эта конфигурация определяет два бина, причем второй зависит от первого. И здесь в игру вступит Spring – когда мы просим предоставить инстанс PaymentProvider — Spring найдет его в контексте и предоставит нам.

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

Сканирование компонентов

Резюме

Spring Boot

Теперь переходим к следующей части. Допустим, нам надо сконфигурить подключение к MySQL базе данных. Если мы хотим использовать Spring Data JPA с Hibernate в качестве провайдера, нам потребуется сконфигурировать несколько бинов — EntityManagerFactory (основной класс JPA), DataSource для подключения непосредственно к базе через JDBC драйвер и т.п. Но с другой стороны, если мы это делаем каждый раз и, по сути, делаем одно и то же — почему бы это не автоматизировать? Скажем, если мы указали строку подключения к базе и добавили зависимость на MySQL драйвер — почему бы чему-то автоматически не создать все нужные бины для работы с MySQL? Именно это и делает Spring Boot. По сути, Spring Boot это просто набор классов конфигурации, которые создают нужные бины в контексте. Точно так же их можно создать руками, просто Boot это автоматизирует.

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

Важное понятие Spring Boot это автоконфигурация. По сути, это просто набор конфигурационных классов, которые создают и регистрируют определенные бины в приложении. По большому счету, даже сам Embedded Servlet Container — это просто еще один бин, который можно сконфигурировать! Пара важных моментов, которые важно знать об автоконфигурации:

Условия и порядок регистрации бинов

Логика при регистрации бинов управляется набором @ConditionalOn* аннотаций. Можно указать, чтобы бин создавался при наличии класса в classpath ( @ConditionalOnClass ), наличии существующего бина ( @ConditionalOnBean ), отсуствии бина ( @ConditionalOnMissingBean ) и т.п.

Spring Boot активно использует эти аннотации чтобы оставаться как можно более незаметным и не перекрывать пользовательские конфигурации.

Погружение в Hello World

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

Итак, наше приложение включает такой код:

Давайте разберем что здесь происходит по шагам.

Класс DemoApplication

Т.е. наличие @SpringBootApplication включает сканирование компонентов, автоконфигурацию и показывает разным компонентам Spring (например, интеграционным тестам), что это Spring Boot приложение

SpringApplication.run()

То получим точно такое же работающее приложение, т.к. класс AnnotationConfigEmbeddedWebApplicationContext найдет в контексте бин типа EmbeddedServletContainerFactory и через него создаст и запустит встроенный контейнер. Обратите внимание, что все это работает в рамках общего DI контейнера, то есть этот класс можно реализовать самим.

@EnableAutoConfiguration

Эта аннотация включает автоконфигурацию. И здесь, пожалуй, ключевой момент в развенчании магии Spring. Вот как объявлена эта аннотация:

Т.е. это самый обычный импорт конфигурации, про который мы говорили выше. Класс же EnableAutoConfigurationImportSelector (и его преемник в Spring Boot 1.5+ — AutoConfigurationImportSelector ) это просто конфигурация, которая добавит несколько бинов в контекст. Однако, у этого класса есть одна тонкость — он не объявляет бины сам, а использует так называемые фабрики.

Класс EnableAutoConfigurationImportSelector смотрит в файл spring.factories и загружает оттуда список значений, которые являются именами классов (авто)конфигураций, которые Spring Boot импортирует.

Т.е. аннотация @EnableAutoConfiguration просто импортирует все перечисленные конфигурации, чтобы предоставить нужные бины в контекст приложения.

По сути, ее можно заменить на ручной импорт нужных конфигураций:

Однако, особенность в том, что Spring Boot пытается применить все конфигурации (а их около сотни). Я думаю, у внимательного читателя уже появилась пара вопросов, которые стоит прояснить.

«Но это же медленно!». И да, и нет — под рукой нет точных цифр, но сам по себе процесс автоконфигурации очень быстрый (порядка сотни миллисекунд на абстрактной машине в вакууме)

Краткое резюме

В основе «магии» Spring Boot нет ничего магического, он использует совершенно базовые понятия из Spring Framework. В кратком виде процесс можно описать так:

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

Диагностика

Auto-configuration report

В ответ Spring выдаст детальный Auto-configuration report:

Строчка в Positive / Negative matches будет для каждой примененной автоконфигурации, более того, Boot сообщит, почему тот или иной бин был создан (т.е. укажет, какие из условий регистрации были выполнены).

Actuator

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

Резюме

Spring все же остается большим и не самым простым фреймворком, но это цена высокоуровневых абстракций, которые он предоставляет. И хотя знать все тонкости работы фреймворка в ежедневной разработке не нужно, знать, как он работает изнутри, все же, полезно. Надеюсь, что эта статья помогла понять важность и ценность Spring именно как экосистемы и убрала немного «магичности» в происходящем, особенно при использовании Spring Boot. Мой совет — не бойтесь углубляться в недра фреймворка, читайте исходники и документацию, благо они у Spring-a почти эталонные, на мой взгляд.

Источник

Подготовка к Spring Professional Certification. Spring Boot

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

Вопросы

Spring Boot — это набор уже настроенных модулей которые работают в Spring Framework и упрощают конфигурирование Spring приложения.

Вот некоторые центральные модули:

Он предполагает что вам надо, основываясь на зависимостях в classpath. “Соглашение над конфигурацией” — он автоконфигурирует Spring специально подобранными настройками, которые потом можно переопределить.

Бин будет создан только если определенная зависимость есть в classpath.

Бин будет создан только если в контейнере нет бина такого типа или с таким именем.

Существует список аннотаций-условий, каждая из которых используется для управления созданием бинов. Вот список таких аннотаций(на самом деле их больше):

Spring Boot использует особый порядок PropertySource’ов для того чтобы позволить переопределять значения свойств. Вот порядок источников для получения свойств приложения:

Также добавлю, что property.yml всегда переопределяют property.properties.

Аннотация @SpringBootApplication предоставляет 3 свойства:

Вот другие основные аннотации:

@EnableConfigurationProperties — позволяет использовать бины с аннотацией @ConfigurationProperties

@ConfigurationProperties — позволяет связывать проперти из файлов с бинами

@WebMvcTest — используется для тестов Spring MVC

@SpringBootTest — используется, когда нужны функции Spring Boot в тестах

@DataJpaTest — используется для теста компонентов JPA

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

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

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

Spring Boot поддерживает Tomcat, Jetty, и Undertow.
По умолчанию используется TomCat. Для того чтобы изменить контейенер, просто добавьте нужную зависимость в pom.xml.

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

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

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

По умолчанию Sprin Boot логирует только в консоль. Если вы хотите логировать события в файл, необходимо установить свойства logging.file или logging.path в true(например, в application.properties).

Цветной вывод сообщений в журнал

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

Если вы хотите, чтобы записать шла в другие файлы, вы также можете это настроить(YAML):

Источник

Spring boot: маленькое приложение для самых маленьких

В этой статье мы научимся создавать простые REST приложения. Напишем свое приложение с использованием SpringBoot, создадим свои контроллеры, воспользуемся JPA, подключим PostgreSQL.

Мы будем разрабатывать приложение в 3 этапа:

Создадим и запустим простое REST приложение на SpringBoot

Напишем приложение с сущностями, создадим контроллеры и подключим JPA

Создадим сущности и репозиторий

Напишем сервисную часть приложения

Запустим и протестируем наше приложение, удивимся, что все работает и порадуемся, что провели время с пользой и узнали что-то новое

1. Создадим и запустим простое REST приложение на SpringBoot

Мы пойдем по простому пути, а точнее зайдем на сайт-стартер проектов на SpringBoot: https://start.spring.io/. Выберем сборку gradle + Java. Запустим и соберем проект локально. Для этого через консоль используем команды, и ждем пока погдрузятся все библиотечки и соберется проект.

./gradlew wrapper — загрузка нужной версии wrapper.

Когда мы используем утилиту gradlew (по сути это оболочка, которая использует gradle), нам не нужно иметь заранее установленный Gradle на своем ПК. Эта оболочка может сама скачать и установить нужную версию, разобрать аргументы и выполнить задачи. По сути, используя gradlew, мы можем распространять/делиться проектом со всеми, чтобы использовать одну и ту же версию и функциональность Gradle. Gradlew читает информацию из файла gradle/wrapper/gradle-wrapper.properties.

Мы собрали наше приложение, но пока оно только запускается, но не выполняет никаких других функций. Заходим в файл build.gradle, можно сказать, что это мозг нашего проекта. Здесь хранится вся основная информация для конфигурации и сборки проекта. Сейчас он выглядит так:

Добавим в dependencies следующую зависимости для работы с PEST API:

@RestController = @Controller + @ResponseBody. Аннотация @Controller умеет слушать, получать и отвечать на запросы. А @ResponseBody дает фреймворку понять, что объект, который вы вернули из метода надо прогнать через HttpMessageConverter, чтобы получить готовое к отправке клиенту представление.

В файл application.properties добавим строку:

Вуаля! Теперь наше приложение не только запускается, но и выводит сообщение «spring_boot_example» по адресу: http://localhost:8080/.

2. Напишем приложение с сущностями, создадим контроллеры и подключим JPA

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

2.1. Создадим сущности и репозиторий

Аннотируем классы следующим образом:

Поле Address в классе User выглядит следующим образом:

Осталось сгенерировать методы hashCode, equals и toString. Для User мы генерируем hashCode и equals только по полю login, этого достаточно, так как мы сделали это поле уникальным и отличным от null. Так же для User при переопределении toString мы не используем поле address. Ранее упоминалось, что инициализация ленивая, и значение для этого поля не подтягивается сразу, а если мы попробуем обратиться к hibernate и попросить достать сущность без @Transactional, то упадем с ошибкой.

Полный код сущностей:

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

JpaRepository – это интерфейс фреймворка Spring Data предоставляющий набор стандартных методов JPA для работы с БД.

2.2. Добавим контроллеры.

Аннотация @Data добавляет get, set, toString, equals, hashCode, конструктор по всем полям, т.е. практически полностью генерирует POJO класс.

Теперь можно создать наш полноценный контроллер. Помечаем класс аннотациями @RestController и @RequestMapping(«/api/v1/users»).

У нашего приложения будет 5 контроллеров. Два на получение данных: всех пользователей и по id, на создание, изменение и удаление данных о пользователе.

Получаем список пользователей:

На аннотацию @GetMapping мы уже смотрели ранее. Свойство produces = APPLICATION_JSON_VALUE говорит о том, что данные возвращаются в формате json. В данном методе мы возвращаем лист с данными UserResponse.

Получаем пользователя по id:

Этот метод аналогичен предыдущему, за исключением того, что мы также получаем id пользователя. Аннотация @PathVariable говорит о том что информация извлекается из адреса и передается в переменную указанную в <>.

Обновляем пользователя по id:

Удаляем пользователя по id:

2.3. Напишем сервисную часть приложения.

Теперь посмотрим на логику сервиса. Для начала создадим интерфейс с пятью методами, а затем унаследуемся от него. Наш интерфейс выглядит так:

Создадим новый класс имплементирующий созданный выше интерфейс:

Теперь добавим логику в каждый метод.

Получаем список пользователей:

Хочу обратить внимание, что раньше мы говорили, что если мы обращаемся к сущности address вне @Transactional метода, то упадем с ошибкой. Так вот, тут такое не произойдет, т.к. метод как раз имеет эту аннотацию, hibernate ее видит и поднимает это поле из БД.

Получаем пользователя по id:

По аналогии с buildUserResponse создадим дополнительный метод buildUserRequest.

Это не самый лучший подход, так как для каждой сущности должны быть свои контроллеры и репозитории. Но в контексте нашего приложения Address и User не могут существовать отдельно, поэтому мы можем воспользоваться этим приемом.

Обновляем пользователя по id:

В этом методе мы находим пользователя, по аналогии с методом findById, если такой объект нашелся, то сетим ему поля в методе userUpdate.

Удаляем пользователя по id:

Теперь добавим свой обработчик ошибок. Spring умеет перехватывать ошибки и возвращать вместо них то, что мы захотим. Для этого создадим объект ExceptionResponse, который будет возвращать только сообщение из ошибки.

3. Запустим и протестируем наше приложение, удивимся что все работает и порадуемся, что провели время с пользой и узнали что-то новое.

Добавим креды для подключения к БД в application.properties:

Теперь поднимем базу (для этого я использую докер) и добавляем таблички в БД.

Ура! Наше приложение написано и полностью работает, теперь его можно тестировать.

Подведем итог. Мы написали простое приложение и затронули несколько важных тем. Разработали контроллеры для разных REST методов, написали сервисную частью, включая свой обработчик ошибок. Подключили JPA и воспользовались методами интерфейса JpaRepository.

Источник