Spring boot starter parent что это
Spring Boot – Starter Parent
The parent of spring-boot-starter-parent looks like the following
Attention reader! Don’t stop learning now. Get hold of all the important Java Foundation and Collections concepts with the Fundamentals of Java and Java Collections Course at a student-friendly price and become industry ready. To complete your preparation from learning a language to DS Algo and many more, please refer Complete Interview Preparation Course.
The following code has to be added in the pom.xml to use spring-boot-starter-parent as a parent project.
Managing dependencies
Any spring boot starter can be included under the dependencies section. If we omit the version for a particular starter, Maven will download the jar files based on the version number defined in the parent section. For example, if we require a data access layer, then we should add spring-data-jpa dependency starter in the pom.xml file.
Dependency Management Tag
If you require a different version of dependency provided by the spring-boot-starter-parent, we can add a particular version inside the tag and include the dependency and its version inside the dependencyManagement section.
Properties
We know that spring-boot-starter-parent configures the java compiler version, Maven plugins version, and Dependencies version using the properties defined inside it. We can override those property values inside the pom.xml file under the properties section. Suppose our project requires a different version of the sl4j library and a different java version.
Using Spring Boot Without a Starter Parent
If we want to inherit from the custom parent POM or define all the Maven configurations manually, we don’t inherit from the spring-boot-starter-parent pom. However, we can still benefit from the dependency management feature(not the plugin management) provided by spring-boot-dependencies, by including the dependency inside the dependencyMangement section as an import scope.
Note: To override the properties of individual dependencies, we need to add those dependencies prior to the addition of spring-boot-dependencies.
Spring Boot стартер для Apache Ignite своими руками
Вот уже вышло две статьи в потенциально очень длинной серии обзоров распределённой платформы Apache Ignite (первая про настройку и запуск, вторая про построение топологии). Данная статья посвящена попытке подружить Apache Ignite и Spring Boot. Стандартным способом подключения некой библиотеки к Spring Boot является создание для этой технологии «стартера». Несмотря на то, что Spring Boot весьма популярен и на Хабре описывался не единожды, про то, как делать стартеры, вроде бы ещё не писали. Этот досадный пробел я постараюсь закрыть.
Статья посвящена преимущественно Spring Boot’у и Spring Core, так что те, кого тема Apache Ignite не интересует, всё равно могут узнать что-то новое. Код выложен на GitHub, стартера и демо-приложения.
При чём тут Spring Boot?
Как известно, Spring Boot это очень удобная вещь. Среди его многочисленных приятных особенностей особенно ценно его свойство путём подключения нескольких maven-зависимостей превратить маленькое приложеньице в мощный программный продукт. За это в Spring Boot’е отвечает механизм стартеров (starter). Идея состоит в том, что можно спроектировать и реализовать некоторую конфигурацию по-умолчанию, которая будучи подключена настроит базовое поведение вашего приложения. Эти конфигурации могут быть адаптивными и делать предположения о ваших намерениях. Таким образом, можно сказать, что Spring Boot закладывает в приложение некоторое представление об адекватной архитектуре, которое он дедуктивно выводит из той информации, которую вы ему предоставили, положив те или иные классы в classpath или указав настройки в property-файлах. В хрестоматийном примере Spring Boot выводит «Hello World!» через веб-приложение, запущенное на встроенном Tomcat’e при буквально паре строчек прикладного кода. Все дефолтные настройки можно переопределить, и в предельном случае прийти к ситуации, как если бы Spring Boot’а у нас не было. Технически, стартер должен обеспечить инжектирование всего, что нужно, предоставляя при это осмысленные значения по-умолчанию.
В первой статье серии было рассказано, как создавать и использовать объекты Ignite. Хотя это и не очень сложно, хотелось бы ещё проще. Например, чтобы можно было воспользоваться таким синтаксисом:
Далее будет описан стартер для Apache Ignite, в который заложено простейшее видение адекватного Ignite-приложения. Пример исключительно демонстрационный и не претендует на то, чтобы отражать какой-либо best practice.
Делаем стартер
Прежде чем сделать стартер, надо придумать, о чём он будет, в чём будет состоять предлагаемый им сценарий использования подключаемой им технологии. Из предыдущих статей мы знаем, что Apache Ignite предоставляет возможность создать топологию из узлов клиентского и серверного типа, и для их описания используются xml-конфигурации в стиле Spring core. Знаем также, что клиенты могут подключаться к серверам и выполнять на них задания. Серверы для выполнения задания могут быть отобраны по каким-то критериям. Поскольку разработчики не предоставили нам описания best practice, для данного простейшего случая я его сформулирую сам так: в приложении должен быть хотя бы один клиент, который будет слать нагрузку на сервера с теми, что и у него, значением gridName.
Руководствуясь этой генеральной идеей наш стартер попытается сделать всё, чтобы приложение не обвалилось при самых минимальных конфигурациях. С точки зрения прикладного программиста это сводится к тому, что надо получить объект типа Ignite и выполнить над ним какие-то манипуляции.
Для начала создадим каркас нашего стартера. Во-первых, подключим maven-зависимости. В первом приближении достаточно будет этого:
Здесь мы подключаем базовый стартер spring-boot-starter-parent, основные зависимости Ignite и Spring. Когда прикладное подключение подключит наш стартер, ему уже это делать не придётся. Следующим шагом надо сделать так, чтобы аннотация @IgniteResource корректно инжектила объект типа Ignite без участия программиста, с возможностью переопределения умолчаний. Сама аннотация довольно простая:
Ожидается, что в аннотированную таким образом переменную заинжектится объект Ignite со свойствами, сообразно заданным. Будет произведён поиск по всем конфигам, и если найдётся подходящий, Ignite будет создан на его основе, если нет, будет принята во внимание настройка createIfNotExists(), и Ignite будет создан на основе дефолтных и переданных значений. Как нам этого добиться? Надо, что бы параметры нашей аннотации были учтены в процессе инстанциации бинов. За этот процесс в Spring отвечают объекты типа ConfigurableListableBeanFactory, а конкретно в Spring Boot это DefaultListableBeanFactory. Естественно, этот класс ничего не знает про Ignite. Напоминаю, что конфигурации Ignite хранятся в виде xml-конфигураций, которые являются Spring-конфигурациями. Или же их можно создать вручную, создав объект типа IgniteConfiguration. Таким образом, надо обучить Spring правильно инжектировать. Поскольку BeanFactory создаётся контекстом приложения, нам надо сделать свой:
Наш контекст отнаследован от AnnotationConfigApplicationContext, но Spring Boot для Web-приложений использует другой класс. Этот случай мы здесь не рассматриваем. Соответственно, Ignite-Spring Boot-приложение должно использовать этот контекст:
Теперь надо настроить BeanFactory. Однако сначала надо позаботиться о душевном спокойствии Spring’а. Spring не дурак, Spring умный, он знает, что если есть @Autowired, то должен быть Bean. Поэтому в наш стартер мы добавим автоконфигурацию:
Она будет загружена при наличии класса org.apache.ignite.Ignite и будет делать вид, что кто-то умеет возвращать объекты Ignite. На самом деле мы тут возвращать ничего не будем, так как отсюда нам не видно конфигурационных параметров, заданных в аннотации @IgniteResource. Подключение автоконфигурации обеспечивается конфигом spring.factories, помещаемым в META-INF, подробности в документации Spring Boot. Возвращаемся к BeanFactory и делаем так:
То есть, если у нас просят объект типа Ignite мы делегируем выполнение IgniteSpringBootConfiguration, о которой ниже, а если нет — оставляем всё, как есть. В IgniteSpringBootConfiguration мы передаём аннотации IgniteResource, навешенные на поле. Продолжаем распутывать этот клубок и смотрим, что это за IgniteSpringBootConfiguration.
Тут мы ссылаемся на property-класс и определяем структуры для хранения данных Ignite. В свою очередь, DefaultIgniteProperties использует механизм «Type-safe Configuration Properties», о котором я рассказывать не буду и отошлю к мануалу. Но важно, что под ним лежит конфиг, в котором определены главные значения по-умолчанию:
Эти параметры могут быть переопределены в вашем приложении. Первый из них указывает, где мы будем искать xml-конфигурации Ignite, остальные определяют свойства конфигурации, которые мы будем использовать, если профиль не нашли и надо создать новый. Далее в классе IgniteSpringBootConfiguration будем искать конфигурации:
Вначале мы ищем уже известные нашему приложению бины типа IgniteConfiguration, а затем ищем конфиги по указанному в настройках пути, и найдя создаём из них бины. Бины конфигураций складываем в кэш. Затем, когда к нам приходит запрос на бин, мы ищем в этом кэше IgniteConfiguration по имени gridName, и если находим — создаём на основе этой конфигурации объект Ignite и прихраниваем, чтобы потом вернуть при повторном запросе. Если нужной конфигурации не нашли, создаём новую на основе настроек:
Теперь изменим стандартное поведение Ignite для выбора серверов, на которые будут распределяться задания, которое состоит в том, что нагрузка распределяется на все сервера. Допустим, мы хотим, чтобы по-умолчанию выбирались сервера, у которых тот же gridName, что и у клиента. В предыдущей статье рассказывалось, как это сделать штатными средствами. Тут мы немного извратимся, и проинструментируем получаемый объект Ignite с помощью cglib. Замечу, что в этом нет ничего ужасного, Spring сам так делает.
И это всё, теперь бины Ignite выдаются согласно настроек. В Spring Boot приложении мы можем вызвать теперь Ignite так:
В JUnit-тестах @IgniteResource работать не будет, это оставляется в качестве упражнения.
Выводы
Сделан простейший стартер для Apache Ignite, позволяющий существенно упростить клиентский код, убирая из него большую часть специфики Ignite. Далее этот стартер можно дорабатывать, сделать для него более удобные настройки, предусмотреть более адекватные умолчания. В качестве дальнейшего развития можно сделать многое, например сделать более прозрачным, чем описано в моей статье, прикручивание Ignite в качестве L2 кэша к Activiti.
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:
Прописываем ему право на исполнение:
И запускаем командой:
Все, приложение запущено.
Теперь, если все сделано правильно, можно открыть сайт нашего проекта в браузере и насладиться результатом.