Comments 10
Очень не однозначное впечатление от статьи.
Стиль вопросов/ответов как бы подразумевает запоминание без понимания.
Слова "магия spring boot" как раз из этого корня.
Не с конкретных "магических" свойств нужно начинать изучение. А из общего понимания.
Что Spring Boot это всего лишь довольно простое ядро (контенеры) и куча адаптированных для того что бы не конфиликтовали между собой "библиотек".
Которые никто не мешает использовать и в не Spring framework.
Один из ярких примеров — вопрос про логирование. SpringBoot? Представляю какая каша в голове возникнет у джунов.
Какие преимущества у Spring Boot?
IMHO: Основное преимущество — то что библиотеки между собой не так конфиликтуют, когда пытаешься эту солянку использовать отдельно (точнее меньше с этим проблем).
А пункт "Проект на Spring Boot может компилироваться в автономный JAR-файл" вообще удивил и заставил улыбнуться.
А ведь кто то заучивать будет это для собеседования...
Основное преимущество — то что библиотеки между собой не так конфиликтуют, когда пытаешься эту солянку использовать отдельно (точнее меньше с этим проблем).
И что в стартерах уже обычно записаны основные настройки, поэтому можно не писать много кода для конфигурации.
Один из ярких примеров — вопрос про логирование. SpringBoot? Представляю какая каша в голове возникнет у джунов.
Про логирование — в доке от Pivotal действительно есть вопрос «Can you control logging with Spring Boot? How?»
В частности по Spring Boot у него достаточно хорошо раскрывается магия стартеров.
С другой стороны еще не встречал людей которые погружались в экосистему спринга и чтоб им всё сразу было понятно. У всех поначалу каша.
А так вообще респект автору за перевод.
Главное преимущество — это все же готовые конфигурации, а помимо этого два других: отсутствие конфликтов версий библиотек и возможность создания одного standalone jar-файла.
возможность создания одного standalone jar-файла.
Вообще то, единый jar файл можно создать практически в любом проекте с любым набором famework и библиотек (maven-assembly-plugin). Это такое же никакое отношение имеет к SpringBoot как логгер (который не имеет прямого отношения framework).
готовые конфигурации
Готовые конфигурации — это дело наживное. Когда много наработок в разных framwork, то они как бы уже есть.
Самое главное, из моего опыта, это отсутствие конфиликтов библиотек. Как только начинаешь делать что то более менее сложное (разные реализации Java EE в одной программе, например) — начинаются пляски с бубном (особенно когда нужно общий jar файл сделать).
Вообще то, единый jar файл можно создать практически в любом проекте с любым набором famework и библиотек (maven-assembly-plugin). Это такое же никакое отношение имеет к SpringBoot как логгер (который не имеет прямого отношения framework).
Не думаю, что maven-assembly-plugin позволит еще и контейнер вроде tomcat или webflux положить внутрь jar-файла. Даже если удастся, придется приложить много сил на его конфигурацию, а это все уже сделано в Spring Boot.
Самое главное, из моего опыта, это отсутствие конфиликтов библиотек. Как только начинаешь делать что то более менее сложное (разные реализации Java EE в одной программе, например) — начинаются пляски с бубном (особенно когда нужно общий jar файл сделать).
Если нужно только отсутствие конфиликтов библиотек, можно только использовать bom-файл, без всего spring boot.
Не думаю, что maven-assembly-plugin позволит еще и контейнер вроде tomcat или webflux положить внутрь jar-файла. Даже если удастся, придется приложить много сил на его конфигурацию, а это все уже сделано в Spring Boot. Так что никакой связи.
Только раз пришлось не общий jar файл использовать. Надо было срочно совместить Metro и Apacht CXF реализации. И то, в основном потому что срочно надо были и некогда было разбираться что там внутри конфликтует при сборке в один jar или переводить все на одну реализацию SOAP
По поводу сервера одном jar…
Предпочитаю grizzly из за совместимости и отсутствие конфликтов с glassfish. Из одних исходников собирается и единый jar с интегрированным grizzly сервером и war файл для сервера приложения glassfish.
Но, есть пара проектов (в наследство достались) где народ, почему то выбрал Jetty и Tomcat в качестве интегрированного сервера. Аналогично, проблем с сборкой и конфигурированием нет. Все просто со сборкой одного jar.
Никакого отношения SpringBoot к способу сборки не имеет. И приложения Spring можно собрать как jar с прикладными классами + либы. Дело вкуса и предпочтений.
Иногда jar+либы удобнее.
И вообще, не понимаю хайпа по SpringBoot. Народ его как икону воспринимает.
Ну один из framework. Ну для ряда задач удобен. Но не более.
Надо было мне как то простую конфигурацию c @ Inject и аспекты только на функции, так для такой задачи Guice мне понравился больше.
Когда понимаешь, как оно на самом деле работает, то "оно само настроилось" в SpringBoot перестает вызывать восторг (!= разочаровывает). Ну настроился "hello word"! Вот счастья то… Шаг вправо, влево и все равно нужно понимать как это на самом деле работает без "магии".
Тема сканирования не до конца раскрыта, что значит если есть в classpach? Магии там нет
что значит если есть в classpach
Classpath — импорты в приложении. Spring Boot проверяет это с помощью Conditional-аннотаций.
Если вы импортируете какие-нибудь классы, то spring это заметит и настроит некоторые бины.
Подготовка к Spring Professional Certification. Spring Boot