спринг бут что это
Введение в Spring Boot: создание простого REST API на Java
Из-за громоздкой конфигурации зависимостей настройка Spring для корпоративных приложений превратилась в весьма утомительное и подверженное ошибкам занятие. Особенно это относится к приложениям, которые используют также несколько сторонних библиотек
Каждый раз, создавая очередное корпоративное Java-приложение на основе Spring, вам необходимо повторять одни и те же рутинные шаги по его настройке:
1. Представляем Spring Boot
Авторы Spring решили предоставить разработчикам некоторые утилиты, которые автоматизируют процедуру настройки и ускоряют процесс создания и развертывания Spring-приложений, под общим названием Spring Boot
Spring Boot — это полезный проект, целью которого является упрощение создания приложений на основе Spring. Он позволяет наиболее простым способом создать web-приложение, требуя от разработчиков минимум усилий по его настройке и написанию кода
2. Особенности Spring Boot
Spring Boot обладает большим функционалом, но его наиболее значимыми особенностями являются: управление зависимостями, автоматическая конфигурация и встроенные контейнеры сервлетов
2.1. Простота управления зависимостями
Чтобы ускорить процесс управления зависимостями, Spring Boot неявно упаковывает необходимые сторонние зависимости для каждого типа приложения на основе Spring и предоставляет их разработчику посредством так называемых starter-пакетов (spring-boot-starter-web, spring-boot-starter-data-jpa и т.д.)
Starter-пакеты представляют собой набор удобных дескрипторов зависимостей, которые можно включить в свое приложение. Это позволит получить универсальное решение для всех, связанных со Spring технологий, избавляя программиста от лишнего поиска примеров кода и загрузки из них требуемых дескрипторов зависимостей (пример таких дескрипторов и стартовых пакетов будет показан ниже)
Например, если вы хотите начать использовать Spring Data JPA для доступа к базе данных, просто включите в свой проект зависимость spring-boot-starter-data-jpa и все будет готово (вам не придется искать совместимые драйверы баз данных и библиотеки Hibernate)
Если вы хотите создать Spring web-приложение, просто добавьте зависимость spring-boot-starter-web, которая подтянет в проект все библиотеки, необходимые для разработки Spring MVC-приложений, таких как spring-webmvc, jackson-json, validation-api и Tomcat
Другими словами, Spring Boot собирает все общие зависимости и определяет их в одном месте, что позволяет разработчикам просто использовать их, вместо того, чтобы изобретать колесо каждый раз, когда они создают новое приложение
Следовательно, при использовании Spring Boot, файл pom.xml содержит намного меньше строк, чем при использовании его в Spring-приложениях
Обратитесь к документации, чтобы ознакомиться со всеми Spring Boot starter-пакетами
2.2. Автоматическая конфигурация
Второй превосходной возможностью Spring Boot является автоматическая конфигурация приложения
После выбора подходящего starter-пакета, Spring Boot попытается автоматически настроить Spring-приложение на основе добавленных вами jar-зависимостей
Например, если вы добавите Spring-boot-starter-web, Spring Boot автоматически сконфигурирует такие зарегистрированные бины, как DispatcherServlet, ResourceHandlers, MessageSource
Если вы используете spring-boot-starter-jdbc, Spring Boot автоматически регистрирует бины DataSource, EntityManagerFactory, TransactionManager и считывает информацию для подключения к базе данных из файла application.properties
Если вы не собираетесь использовать базу данных, и не предоставляете никаких подробных сведений о подключении в ручном режиме, Spring Boot автоматически настроит базу в памяти, без какой-либо дополнительной конфигурации с вашей стороны (при наличии H2 или HSQL библиотек)
Автоматическая конфигурация может быть полностью переопределена в любой момент с помощью пользовательских настроек
2.3. Встроенная поддержка сервера приложений — контейнера сервлетов
Каждое Spring Boot web-приложение включает встроенный web-сервер. Посмотрите на список контейнеров сервлетов, которые поддерживаются «из коробки»
Разработчикам теперь не надо беспокоиться о настройке контейнера сервлетов и развертывании приложения на нем. Теперь приложение может запускаться само, как исполняемый jar-файл с использованием встроенного сервера
Если вам нужно использовать отдельный HTTP-сервер, для этого достаточно исключить зависимости по умолчанию. Spring Boot предоставляет отдельные starter-пакеты для разных HTTP-серверов
Создание автономных web-приложений со встроенными серверами не только удобно для разработки, но и является допустимым решением для приложений корпоративного уровня и становится все более полезно в мире микросервисов. Возможность быстро упаковать весь сервис (например, аутентификацию пользователя) в автономном и полностью развертываемом артефакте, который также предоставляет API — делает установку и развертывание приложения значительно проще
3. Требования к установке Spring Boot
Для настройки и запуска Spring Boot приложений требуется следующее:
4. Создание Spring Boot приложения
Теперь давайте перейдем к практике и реализуем очень простой REST API для приема платежей, используя возможности Spring Boot
4.1. Создание web-проекта с использованием Maven
Создайте Maven-проект в используемой вами IDE, назвав его SpringBootRestService
Обязательно используйте версию Java 8+, поскольку Spring Boot не работает с более ранними версиями
4.2. Конфигурация pom.xml
Вторым шагом необходимо настроить Spring Boot в файле pom.xml
Все приложения Spring Boot конфигурируются от spring-boot-starter-parent, поэтому перед дальнейшим определением зависимостей, добавьте starter-parent следующим образом:
Т.к. мы создаем REST API, то необходимо в качестве зависимости использовать spring-boot-starter-web, которая неявно определяет все остальные зависимости, такие как spring-core, spring-web, spring-webmvc, servlet api, и библиотеку jackson-databind, поэтому просто добавьте в pom.xml следующее:
Теперь следующие jar-библиотеки автоматически импортируются в ваш проект:
Следующий шаг — добавляем Spring Boot плагин:
Последний шаг — сделать так, чтобы Maven генерировал исполняемый jar-файл при сборке:
Ниже приведен полный файл pom.xml:
Как видите, используя одну зависимость, мы можем создать полностью функциональное web-приложение
4.3. Создание ресурсов REST
Теперь мы собираемся создать контроллер платежей вместе с POJO-классами для запросов и ответов
Напишем класс запроса платежа:
А также класс, обрабатывающий базовый ответ, возвращаемый нашим сервисом:
А теперь создадим контроллер:
4.4. Создание основного класса приложения
Этот последний шаг заключается в создании класса конфигурации и запуска приложения. Spring Boot поддерживает новую аннотацию @SpringBootApplication, которая эквивалентна использованию @Configuration, @EnableAutoConfiguration и @ComponentScan с их атрибутами по умолчанию
Таким образом, вам просто нужно создать класс, аннотированный с помощью @SpringBootApplication, а Spring Boot включит автоматическую настройку и отсканирует ваши ресурсы в текущем пакете:
5. Развертывание приложения Spring Boot
Теперь давайте воспользуемся третьей замечательной особенностью Spring Boot — это встроенный сервер. Все, что нам нужно сделать — это создать исполняемый jar-файл с помощью Maven и запустить его, как обычное автономное приложение:
Наш REST API запущен и готов обслуживать запросы через порт 8080 (по умолчанию)
В этой статье мы рассмотрели возможности Spring Boot и создали полностью рабочий пример с использованием встроенного сервера
В переводе обновили информацию:
UPDATE:
Как заметил Lure_of_Chaos, теперь уже все можно сделать автоматически через SPRING INITIALIZR. Причем не выходя из любимой JetBrains IntelliJ IDEA.
Spring Boot: от начала до продакшена
В данной статье я попробую расписать все шаги, которые потребуются для создания небольшого проекта на Spring Boot и развертывания его на боевом сервере.
Не будем тянуть долгими прелюдиями о философии java и spring’а, и сразу приступим к делу.
Для начала нам необходимо создать каркас приложения, внедрив туда весь необходимый зоопарк технологий(как минимум Spring, JPA, JDBC). До появления spring boot нужно было потратить на это немало времени, если конечно у вас не было рабочей заготовки в закромах кода. И именно сложность создания подобного каркаса, как мне кажется, останавливает многих от разработки небольших веб-проектов на java. Конечно, когда-то был хромой spring roo, который мог создать подобный каркас в ущерб производительности(привет аспектам), но даже с ним количество и сложность конфигурационных файлов заставляли долго медитировать над ними неподготовленного разработчика. Однако теперь с приходом Boot и Spring 4 жизнь стала немного проще и количество конфигурационных файлов заметно уменьшилось.
Если же у вас нет данной IDE, то скачиваем Spring Boot CLI, следуем инструкции в INSTALL.txt. Нужно задать системную переменную SPRING_HOME(путь к папке со Spring Boot, не к папке bin!) и добавить путь к SPRING_HOME/bin в системную переменную PATH на windows.
Итак, консоль спринга настроили, теперь самое время создать проект. Сделать это можно следующей командой:
UPDATE
Кроме того, как написали в комментариях, существует еще веб-конструктор: start.spring.io
Далее импортируем получившийся каркас в любимую IDE и начинаем его модифицировать под наши нужды.
Для начала добавим в каталог src/main папку webapps. Все веб-ресурсы мы будем создавать в ней, а не в папке resources, как хочет того спринг. Дело в том, что если мы будем создавать файлы в папке resources, то тогда мы лишимся возможности видеть изменения, сделанные в наших веб-ресурсах, без перезагрузки сервера. А это может быть неприятно, когда ради того, чтобы посмотреть изменившийся текст на веб-странице приходится перезапускать веб-сервер.
Теперь в папке webapps создаем файл index.html и папки css, js, font, images, в которые будем класть соответствующие ресурсы.
Для примера сделаем самый простой каркас index.html:
Изменим файл pom.xml
Должно получиться что-то подобное:
Из pom-файла мы можем увидеть следующее:
Мы используем java 8(самое время ее попробовать). Наш класс приложения называется com.yourcompany.Application(не забудьте переименовать стандартно сгенерированный класс, который может называться к примеру DemoApplication).
Мы используем postgresql 9.4(тоже неплохо бы установить его локально на свою машину). Connection pool для взаимодействия с базой данных мы берем самый модный и производительный (HikariCP). Кроме того, мы используем специальный плагин, который, когда мы будем генерировать итоговый jar’ник, перенесет все наши данные из webapp в resources/static, как того хочет spring boot. В противном случае вы не сможете увидеть все те веб-страницы, что создадите в папке webapps, когда запустите jar-ник.
Добавим пакет config и создадим в нем класс JpaConfig:
Кроме того, добавим в файл application.properties следующие строчки:
И наконец в Application.java меняем строку инициализации на следующую:
Тем самым мы настроили подключение к СУБД PostgreSQL.
Не забываем создать саму базу данных и простенькую таблицу в ней. Сделать это удобнее всего через PgAdmin.
Создав в ней пустую базу yourapp_data, выполняем скрипт создания таблицы:
Теперь настало время немного заняться начинкой нашего проекта. А именно добавить какую-нибудь сущность БД и научиться с ней работать, получая с клиента данные для ее формирования и отправляя клиенту же данные об уже созданных сущностях.
Создаем пакеты controller, entity, repository, service, utils.
В пакете entity создаем интерфейс:
Аннотации JPA и Hibernate в данном примере использовать не будем, так как эти технологии сильно замедляют работу(запрос может выполняться в 10 раз медленнее, чем на чистом jdbc), а так как у нас нет сильно сложных сущностей, для которых реально может потребоваться ORM, то воспользуемся обычным jdbcTemplate.
Создаем интерфейс репозитория:
Вместо уже упомянутого jdbcTemplate, мы, как видите, используем JdbcOperations, который является его интерфейсом. Нам приходится использовать везде интерфейсы, отделяя их от реализации, так как, во-первых это стильно, модно, молодежно, а во-вторых, spring в нашем случае использует стандартный jdk’шный Proxy для наших объектов, поэтому напрямую инжектить реализацию не получиться, пока мы не введем полноценные аспекты и AspectJ compile-time weaving. В нашем случае этого и не требуется, чтобы не перегружать приложение.
Осталось уже немного. Создаем наш сервис(мы же хорошие разработчики и должны отделить бизнес-логику от логики работы с СУБД?).
Отлично. Теперь создаем пару вспомогательных классов, необходимых для реализации контроллера:
Это наша реализация Exception’а. Может пригодиться в будущем, хотя и не обязательна, но на нее завязан следующий класс:
Если мы словили такую ошибку в нашем контроллере, то она будет обработана дополнительно в этом методе.
Наконец напишем небольшой классик, который будет формировать структуру данных для передачи на клиент:
Все, со вспомогательными классами закончили. Осталось написать наш контроллер. Он будет простым, как пробка:
В нем два метода — сохранить полученные данные и выдать порцию случайных данных на клиент. Контроллер унаследован от созданного нами ранее ExceptionHandlerController. Обработка исключений написана только как шаблон и нуждается в соответствующей доработки под себя.
Итак, основная часть серверного кода написана, осталось проверить его работу на клиенте. Для этого нужно доработать наш файл index.html и заодно добавить библиотеку jquery в каталог js.
index.html:
Да, UI получился не бог весть каким красивым, но зато с его помощью мы можем проверить работу приложения.
Запустим наш проект. В Intellij Idea это можно сделать через специальную конфигурацию запуска(Spring Boot).
Если все сделано верно, то по адресу localhost:8080 вы сможете увидеть заголовок Hello World, строку ввода и две кнопки. Попробуйте ввести что-нибудь в строку ввода и нажать на кнопку POST. Если после этого вы увидите аналогичный текст ниже поля ввода, то все работает как надо. Теперь останется модифицировать проект под свои нужды, добавить модный UI(например materializecss.com) и творить разумное, доброе, вечное.
Однако рано или поздно вы сотворите желаемое и встанет вопрос о том, как донести ваше детище в массы. Об этом будет вторая часть статьи.
Начнем с малого, но важного.
Даже если проект небольшой, все равно для него потребуется свой домен. Если вы просто обкатываете какую-нибудь идею и не хотите тратить бешеные деньги для регистрации домена на том же godaddy, то можете воспользоваться бесплатной альтернативой: freenom.com
Далее займемся сервером, где все это будет крутиться. Так как проект у нас небольшой, то и сервер нам сгодится небольшой. В идеале хватит VPS. Достать его можно в разных местах, например www.digitalocean.com
Итак, регистрируемся, создаем самый простой дроплет и ставим на него ubuntu (в моем случае это ubuntu 12.04, дальнейшие инструкции буду описывать для этой системы, но на остальных будет примерно то же)
Отлично, у нас есть сервер, пора залить на него наш проект.
Но не будем унывать, поставим себе новую версию:
Теперь настала очередь postgres’а. До этого мы использовали локальную версию на машине разработчика, теперь пришло время поставить СУБД на сервер.
Для этого сначала выполняем магическую последовательность команд:
Далее выполняем команду входа в psql:
И выходим c помощью команды \q
Редактируем файл /etc/postgresql/9.4/main/postgresql.conf, изменив строчку #listen_addresses = ‘localhost’ на listen_addresses = ‘*’
Тем самым мы сможем подключаться к postgresql извне с помощью pgadmin’а. Хотя, конечно, желательно этого избежать в целях безопасности, и когда все будет настроено и отлажено, отключить эту возможность.
Затем редактируем файл /etc/postgresql/9.4/main/pg_hba.conf
Должны быть добавлены две новых строчки и изменена одна строка для 127.0.0.1 следующим образом:
Я намеренно изменил md5 на trust, так как лично у меня были проблемы с запуском проекта, тем самым отключив проверку пароля для заданных адресов. Возможно у вас их не будет.
Теперь все настроено. Хотя тюнинговать постгрес можно до бесконечности, но ведь у нас всего лишь маленький проект, а значит, пока оставим как есть.
Перезапускаем postgres: и проверяем его работу.
Всё, с настройкой postgres’а закончили, что у нас дальше по сценарию?
В моем случае корневой директорией nginx была /etc/nginx. Там нам в первую очередь потребуется изменить файл /sites_available/default следующим образом:
Однако и это еще не все. Необходимо также модифицировать наш проект, чтобы он поддерживал настроенный нами прокси. Благо сделать это не трудно, достаточно лишь в application.properties добавить строки(не забудьте залить новую версию с изменениями):
Теперь можно запустить nginx командой service nginx start и затем попробовать запустить наш проект. Он будет доступен по ссылке сайта, либо же, если вы еще не приобрели домен, то по его ip-адресу, без указания порта.
Остался еще один небольшой штрих. Немного неудобно всегда стартовать проект тем способом, который был описан выше. Неплохо бы, чтобы при старте проекта консоль ввода на сервере освобождалась, приложение не закрывалось бы после выхода из ssh-сессии и чтобы где-нибудь велись логи приложения. Сделать это можно с помощью команды nohup. Предварительно создаем bash-скрипт, называя его script.sh:
Прописываем ему право на исполнение:
И запускаем командой:
Все, приложение запущено.
Теперь, если все сделано правильно, можно открыть сайт нашего проекта в браузере и насладиться результатом.
Миграция Spring Boot приложения на Java 17 — сложный путь
Недавно была выпущена Java 17, и я очень рад появлению множества улучшений и новых функций. Вместо того, чтобы начинать с нового или недавнего проекта (где в этом азарт?), мы собираемся обновить существующее приложение Spring Boot, пока мы не сможем разработать новый код с использованием Java 17.
День первый
Если ваша ситуация похожа на нашу, у вас могут быть старые приложения, успешно работающие в производственной среде, которые не обновлялись некоторое время. К сожалению, это все еще обычная практика.
Многие корпорации придерживаются политики, запрещающей версии JDK, отличные от LTS. Это делает Java 17 таким привлекательным для многих из нас. По прошествии стольких лет у нас наконец-то появилась LTS-версия, которую мы можем использовать при разработке наших корпоративных приложений.
Мы хотели бы использовать Java 17 в одном из наших существующих проектов, поэтому я надеюсь, что вы продолжите наше путешествие. Вместе мы собираемся сделать это и по пути кое-чему научиться.
Настройка
Наш проект представляет собой монорепозиторий, содержащий
Чтобы дать вам представление о том, о чем мы говорим, все следующие проекты Spring используются в нашем проекте и одним или несколькими приложениями:
Java 17
Давайте создадим проект на Java 17. В среде IDE переключите JDK на Java 17, а в родительском POM установите для java.version свойства значение 17.
Скомпилируем приложение и посмотрим, что получится… барабанная дробь, пожалуйста.
К сожалению, наш проект не скомпилировался, что неудивительно. Давайте посмотрим на эту ошибку Lombok.
Lombok
Версия 1.18.12 не указана напрямую в нашем проекте. Как и большинство общих зависимостей, она управляется зависимостями Spring Boot. Однако мы можем переопределить версию зависимости из Spring Boot.
В родительском элементе pom.xml мы можем переопределить версию Lombok через свойство:
Теперь, когда мы обновили версию, посмотрим, компилируется ли она:
Класс ValueMapper делает то, что следует из названия: он сопоставляет класс Value с AppEntity с помощью MapStruct. Странно, мы только что обновили Lombok, поэтому Java-бины должны быть сгенерированы правильно. Это должно быть проблема с MapStruct, так что давайте посмотрим.
MapStruct
Мы используем MapStruct вместе с Lombok, позволяя Lombok генерировать геттеры и сеттеры для наших Java бинов, в то же время позволяя MapStruct генерировать преобразователи между этими bean-компонентами.
MapStruct использует сгенерированные геттеры, сеттеры и конструкторы и использует их для создания преобразователей.
Этого было достаточно, чтобы скомпилировать код и запустить наши модульные тесты. К сожалению, наши интеграционные тесты все еще не работают и выдают следующую ошибку:
Давайте посмотрим на эту ошибку ASM.
Spring, используя CGLIB и ASM, генерирует прокси-классы, несовместимые со средой выполнения Java 17. Spring Boot 2.3 зависит от Spring Framework 5.2, который использует версию CGLIB и ASM, несовместимую с Java 17.
Обновление библиотек CGLIB или ASM на этот раз невозможно, поскольку Spring переупаковывает ASM для внутреннего использования. Придется обновить Spring Boot.
Spring Boot
Согласно документу поддержки Spring Boot, Spring Boot 2.3.x достиг EOL в мае 2021 года (версия OSS). Уже одного этого достаточно для обновления, кроме желания использовать Java 17. Дополнительную информацию см. в политике поддержки Spring Boot.
Поддержка Spring Boot и Java 17
Я не нашел официального заявления о поддержке Java 17 для Spring Boot 2.5.x или Spring Framework 5.3.x. Они объявили, что Java 17 будет базовой версией Spring Framework 6, что подразумевает официальную поддержку Java 17 начиная с Spring 6 и Spring Boot 3.
При этом, как говорится, они сделали много работы для поддержки Java 17 в Spring Framework 5.3.x и Spring Boot 2.5.x и внесли в список поддерживаемых JDK 17 и JDK 18 в Spring Framework 5.3.x. Но какая конкретная версия исправления поддерживает Java 17?
Я обнаружил ответ на этот вопрос на GitHub. Поддержка документов для Java 17 # 26767 с тегом версии 2.5.5. Это круто и достаточно для меня.
Примечания к версиям
Поскольку мы обновляем Spring Boot 2.3 до 2.5, я довольно часто ссылался на примечания к версиям для обоих. Вот они:
* Примечания к версии Spring Boot 2.4
* Примечания к версии Spring Boot 2.5
* Примечания к версии Spring Framework
Spring Boot 2.5.x
Мы обновили версию Spring Boot, и теперь начинается самое интересное.
JUnit и отсутствующее свойство spring-boot.version
Моя IDE сообщает, что свойство spring-boot.version больше не определено. Оно было удалено из spring-boot-dependencies, кажется, оно было введено случайно, и его не должно было там быть. Ой.
Мы используем это свойство, чтобы исключить junit-vintage-engine из нашего проекта, поскольку мы уже обновили все наши тесты до JUnit 5. Это запрещает кому-либо случайно использовать JUnit 4.
Мы исключили junit-vintage-engine используя свойство spring-boot.version :
Jackson
После обновления до Spring Boot 2.5.7 некоторые из наших тестов завершились неудачно со следующей ошибкой:
Об этой проблеме уже сообщалось на GitHub, и, как всегда, команда Spring дает отличное объяснение проблемы и способов ее решения.
С конфигурацией по умолчанию Spring Boot 2.5 сериализация типов java.time.* в JSON должна работать в 2.5 точно так же, как в 2.4 и ранее. ObjectMapper будет автоматически сконфигурирован с модулем JSR-310 и java.time.* типы будут сериализованы в формате JSON в их ожидаемой форме.
Здесь изменилось то, что происходит, когда модуль JSR-310 недоступен для Jackson. Из-за изменения в Jackson 2.12 это теперь приведет к сбою сериализации, а не к тому, чтобы Jackson сбоил и сериализовался в неожиданный формат.
Автоконфигурация Jackson
Самый важный вывод заключается в следующем:
Как описано в документации, определение ObjectMapper или вашего собственного Jackson2ObjectMapperBuilder отключит автоконфигурацию. В этих двух случаях регистрация модуля JSR 310 будет зависеть от того, как был настроен ObjectMapper или использовался построитель.
Валидатор запросов Swagger от Atlassian
Это была единственная библиотека, которую мы использовали, у которой были какие-либо проблемы с Jackson, но у вас могут быть и другие. Обязательно используйте последнюю версию ваших библиотек, которая обычно включает такие исправления.
Итоги первого дня
Не знаю, как вы, но я устал, и мне нужен перерыв. Это отличное место, чтобы остановиться на сегодня, наш код компилируется, и наши модульные тесты зеленые. Отличная работа на текущий момент.
Надеюсь, вы присоединитесь к нам на второй день, потому что наше путешествие только началось. Когда мы продолжим, мы увидим, что наши интеграционные тесты не работают, и подробно рассмотрим, почему.
Я хотел бы услышать о вашем опыте миграции Spring Boot. Пожалуйста, оставляйте комментарии или не стесняйтесь обращаться ко мне. Мы кодоцентричны и готовы помочь.
[Обновление] Забыл упомянуть, что мы переходим с Java 11.