Pull to refresh

Comments 40

Перевод отличный.
А вот содержание, кажется, спорное!
Это, конечно, вопрос к автору англоязычной статьи, но голые утверждения о том, что «Spring уже не рассматривается как современный инновационный инструмент», выглядят необоснованными.
Нужно еще принять во внимание ориентацию автора на тенденции среди западных (американских) разрабочиков
Не такие резкие, но близкие по сути выводы можно сделать исходя из следующего материала (слайды 39 — 43). Как продемонстрировано там, более «молодые» фреймворки получили более высокие оценки, чем Spring, или очень плотно к нему приблизились. Кроме этого, достаточно интересные результаты представлены тут.
Ну вы же понимаете, что все такие результаты субъективны)
пробовал я писать свой проект поверх boot
ага-ага, хелоуволды то пишутся легко и быстро, но чуть шаг в сторону — начинается чехарда со spring аннотациями\xml-ми и тому подобным
Главное, чтобы конфигурационный класс с @ComponentScan hello world'а был хоть в каком-нибудь пакете (не в корне), то у новичка крышу сорвёт)
Намерения у разработчиков Spring Boot довольно благие, но как показали комментарии разработчиков на разнообразных форумах, подтвержденное и Вашим комментарием, его основной проблемой является высокая сложность кастомизации, особенно после создания проекта. Очевидно вызвана такая ситуация отсутствием наглядности, ведь фактически весь процесс конфигурации спрятан так сказать «под капот».
Возможно в будущем появится более детальная информация по принципам работы данного инструмента, руководства и примеры решения сложных проблем разработки, что сможет исправить существующие сегодня недостатки.
Ещё они очень любят запихать свой parent POM, что не всегда удобно. Можно, конечно, обойтись без этого, но придется копировать существенный кусок dependency management, что резко снижает полезность сабжа, imho.
Вы же можете сделать свой parent pom.xml и вынести в него все что вы не хотите видеть в основном файле конфигурации.
Я и использую. Только держать пачку parent (с поддержкой boot и без оной) может быть не очень удобно.

Плюс я не люблю bom-like parent pom (с dependencyManagement, включающим сторонние библиотеки), т. к. оно приводит к трудноуловимым багам. Например, вы в проекте зависите от какой-нибудь библиотеки A транзитивно зависящей от библиотеки B версии X. В spring-boot-starter-parent прописана B версии Y (отсутствие прямой и/или обратной совместимости между версиями X и Y), на которой A ломается. Увидев такое безобразие вы прописываете в dependencies библиотеку B версии X. Таким нехитрым образом можно получить крайне неприятный и относительно трудноуловимый баг, который вылезет в недрах того же spring boot'а или его компонентов.
Можете описать один-два таких момента? А то я как раз выбрал Spring Boot, как раз написал Hello World и теперь вот прочитал ваш коммент и загрустил.
Когда есть опыт работы со спрингом, особых проблем с кастомизацией не возникает. Если хочется что-то настроить под себя — просто смотришь исходники соответствующего класса автоконфигурации, и либо переделываешь его с нуля, либо меняешь соответствующие бины. Но если опыта нет, то будет тяжело во всём этом разбираться.
Пара неприятных проблем, которые мне встречались:
При сабмите www-url-encoded формы кодировка определялась как ISO-8859-1. Быстро вылечилось заменой томката на джетти. Потом выяснил, что можно пофиксить добавлением соответствующего фильтра в цепочку spring security.
Пара библиотек отказалась работать со вложенными jar'ами — пришлось дописать лишнюю сотню строк кода.
Thymeleaf под себя дорабатывать довольно трудно, но это с непривычки и к спрингу мало относится.
>Если хочется что-то настроить под себя — просто смотришь исходники соответствующего класса автоконфигурации, и либо переделываешь его с нуля
>переделываешь
>лечилось заменой
>дописать
в этом весь спринг бут, спасибо
В этом весь %любойфреймворк%.
По большому счёту, бут — это набор стартовых конфигов. Править и переделывать их — естественная задача. А чтобы их править, надо для начала изучить спринг DI, WebMvc, Security, Data и кучу всего прочего, что бут настраивает по умолчанию.
Вы до этого со спрингом много работали? «Чехарда с xml и аннотациями» вообще не должна возникать — в новом проекте должно использоваться либо то, либо другое.
почему смешанное использование xml и аннотаций это чехарда? и почему либо одно либо другое?
Чехарда — это цитата из первого комментария ветки — поленился правильно выделить.
Смешивание разных способов конфигурации почти всегда усложняет структуру приложения. Поначалу кажется, что «а ладно, здесь я проще добавлю xml с нэймспейсом», а через год-другой там уже десятки файлов от разных разработчиков друг друга дёргают. Это в худшем случае, конечно, но всё равно лишний риск.
со спрингом работал много
когда я попытался сделать standalone rest сервер который бы отдавал не только crud, но и немного логики, я был сильно огорчён тем, что всё снова пришлось делать руками, и тогда нет разницы, использовать spring boot или, например, jersey
А, тогда не спорю. Преимущество бута, на мой взгляд, в том, что можно быстро получить рабочую версию приложения, а потом уже, по мере необходимости, настраивать её под себя. Время, затрачиваемое на настройку не исчезает, но более плавно распределяется по периоду разработки.
У меня Thymeleaf в одном из проектов. Дорабатывался легко.
Да с автоконфигурациями можно наступить на грабли, если нужно что-то конкретно переделать, но в таком случае, лучше отключить нужную автоконфигурацию и написать свою с нуля.
Я долго разбирался, как сделать своё переписывание ссылок внутри @{}. В итоге остановился на костыльной обёртке вокруг CsrfRequestDataValueProcessor. Наверно, это можно как-то сделать через диалекты и процессоры атрибутов, но пока и так сойдёт.
UFO just landed and posted this here
Его, собственно, и не любят за:
— многословность,
— неудобство редактирования без специализированного редактора.
Выходит — за то же за что и Java'у )
Кстати, на одном видео с jug.ru был показан бенчмарк, в котором java-конфигурация загружалась медленнее, чем xml.

Мне еще нравится xml тем, что при необходимости, можно залезть в war-ку, и в xml законфигурировать разные параметры, и все это заработает без перекомпиляции. Незаслуженно недооценивают xml (те, кто его хаят).
Ничего страшного. Временем загрузки можно и пожертвовать. В джава конфигах еще и проксей по-моему много создается, поэтому вызов вашего метода тоже замедляется. Мне нравится практика скрещивания описаний, что-то в xml, что-то аннотациями. В последнее время смотрю уже на groovy конфиг. Скорее бы идея с ним научилась нормально работать)
Есть видео, как за 20 минут сделать минимальный проект с базой данных на scala и play www.youtube.com/watch?v=eNCerkVyQdc
Есть аналогичные про python+django, есть про GWT, vaadin и много других. А вот видео про то, как сделать чего-то осязаемое на spring за 10-20 минут или даже за час я не нашёл, хоть и старался. О чём-то это говорит.
куплю книжку «Spring Framework For Dummies» — добавлю в коллекцию к «Java Programming. 24-Hour Trainer»
В случае thymeleaf вам нужно подрубить только зависимость и написать main класс. Минимальный проект выходит за 1 минуту. Хотя это смотря, что считать «минимальным проектом»
Просто Spring это не игрушка на 20 минут. Это, безусловно, сложный инструмент, но одновременно и очень мощный, с огромными возможностями. Ведь на Boeing тоже не учат летать за 20 минут
Пишу уже второй небольшой проект (на буте + ангуляре) в свободное от работы время. Когда искал на что бы пересесть кроме приевшегося jee стека, наткнулся на спринг бут, и остался очень доволен. Используя только spring.io с документашками, поднял всё что мне было нужно и без особых проблем. Самый большой затык был разве что в data rest. Долго не мог понять почему не получалось сменить base url для рестов. В остальном вещь просто отличная. Если добавить генерилку jpa сущностей, то по уровню spring boot можно сравнить с обычным скаффолдингом в рельсах.
Дык entity может идея из базы сгенерить)
Но для этого надо сделать базу, а это тоже иногда лень ) Мне проше писать сучности jpa и потом уже в базу сливать )
А в большом проекте всё равно как-то лучше вначале нарисовать примерную uml с классами и по ней нагенерить.
Используем Spring Boot в своих проектах, в целом удобно, но кастомизация — боль.
Однако для своих маленьких проектов он удобен. Если надо что-то быстро запустить — лучший выбор.
Лично для меня, само собой.
А уточните в чем конкретно боль, возможно уже пройденные грабли.
Довольно сложно настроить под себя. Он уже идет с набором библиотек и стандартных конфигов, если надо что-то свое, то настройка превращается в исключение зависимостей и выключение некоторых функций, плюс громоздкие конструкции вида
@ComponentScan(basePackages = {"my.company"},
        excludeFilters = {
                @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, value = ApiGlobalMethodSecurityConfiguration.class),
                @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, value = ApiGlobalMethodSecurityConfiguration.ApiWebSecurityConfigurationAdapter.class)
        }
)
@EnableAutoConfiguration(exclude = {WebMvcAutoConfiguration.class})
@ImportResource({"classpath:portal-hazelcast.xml", "classpath:springmvc-resteasy.xml"})
@EnableCaching

или
    @Bean
    public EmbeddedServletContainerCustomizer containerCustomizer() {

        return new EmbeddedServletContainerCustomizer() {

            @Override
            public void customize(ConfigurableEmbeddedServletContainer factory) {
                if (factory instanceof TomcatEmbeddedServletContainerFactory) {
                    TomcatEmbeddedServletContainerFactory containerFactory = (TomcatEmbeddedServletContainerFactory) factory;
                    LOG.info("SSL {}", sslEnabled ? "enabled" : "disabled");
                    if (sslEnabled) {

                        LOG.info("Using keystore {}", getKeystorePath());

                        containerFactory.addConnectorCustomizers(new TomcatConnectorCustomizer() {

                            @Override
                            public void customize(Connector connector) {
                                connector.setSecure(true);
                                connector.setScheme("https");
                                connector.setAttribute("keyAlias", keyAlias);
                                connector.setAttribute("keystorePass", keystorePass);
                                try {
                                    final File file = ResourceUtils.getFile(getKeystorePath());
                                    if (!file.exists()){
                                        throw new FileNotFoundException(getKeystorePath() + " is not found");
                                    }
                                    connector.setAttribute("keystoreFile", file.getAbsolutePath());
                                } catch (FileNotFoundException e) {
                                    throw new IllegalStateException("Cannot load keystore:" + e.getMessage(), e);
                                }
                                connector.setAttribute("clientAuth", "false");
                                connector.setAttribute("sslProtocol", "TLS");
                                connector.setAttribute("SSLEnabled", true);
                            }
                        });
                    }
                }
            }
        };
    }

Не знаю насколько оправдано использование Spring Boot. Для реального проекта не принципиально, потрачу ли я десять минут на подключение зависимостей и написание конфигурации. Также не могу понять полезность spring-boot:run если всю жизнь можно было пускать embedded Jetty container из main(). В большом проекте с кучей профайлов и зависимостей сведется на нет все преимущества автоконфигурирования.
Простите, не нашел ссылки на оригинал
В самой нижней части статьи (там, где отображается количество просмотров и т.п.) есть ссылка «Steve Perkins»
Sign up to leave a comment.

Articles