Comments 40
Перевод отличный.
А вот содержание, кажется, спорное!
Это, конечно, вопрос к автору англоязычной статьи, но голые утверждения о том, что «Spring уже не рассматривается как современный инновационный инструмент», выглядят необоснованными.
А вот содержание, кажется, спорное!
Это, конечно, вопрос к автору англоязычной статьи, но голые утверждения о том, что «Spring уже не рассматривается как современный инновационный инструмент», выглядят необоснованными.
+7
Нужно еще принять во внимание ориентацию автора на тенденции среди западных (американских) разрабочиков
+1
Не такие резкие, но близкие по сути выводы можно сделать исходя из следующего материала (слайды 39 — 43). Как продемонстрировано там, более «молодые» фреймворки получили более высокие оценки, чем Spring, или очень плотно к нему приблизились. Кроме этого, достаточно интересные результаты представлены тут.
+1
пробовал я писать свой проект поверх boot
ага-ага, хелоуволды то пишутся легко и быстро, но чуть шаг в сторону — начинается чехарда со spring аннотациями\xml-ми и тому подобным
ага-ага, хелоуволды то пишутся легко и быстро, но чуть шаг в сторону — начинается чехарда со spring аннотациями\xml-ми и тому подобным
0
Главное, чтобы конфигурационный класс с
@ComponentScan
hello world'а был хоть в каком-нибудь пакете (не в корне), то у новичка крышу сорвёт)+1
Намерения у разработчиков Spring Boot довольно благие, но как показали комментарии разработчиков на разнообразных форумах, подтвержденное и Вашим комментарием, его основной проблемой является высокая сложность кастомизации, особенно после создания проекта. Очевидно вызвана такая ситуация отсутствием наглядности, ведь фактически весь процесс конфигурации спрятан так сказать «под капот».
Возможно в будущем появится более детальная информация по принципам работы данного инструмента, руководства и примеры решения сложных проблем разработки, что сможет исправить существующие сегодня недостатки.
Возможно в будущем появится более детальная информация по принципам работы данного инструмента, руководства и примеры решения сложных проблем разработки, что сможет исправить существующие сегодня недостатки.
0
Ещё они очень любят запихать свой parent POM, что не всегда удобно. Можно, конечно, обойтись без этого, но придется копировать существенный кусок dependency management, что резко снижает полезность сабжа, imho.
0
Вы же можете сделать свой parent pom.xml и вынести в него все что вы не хотите видеть в основном файле конфигурации.
0
Я и использую. Только держать пачку parent (с поддержкой boot и без оной) может быть не очень удобно.
Плюс я не люблю bom-like parent pom (с
Плюс я не люблю bom-like parent pom (с
dependencyManagement
, включающим сторонние библиотеки), т. к. оно приводит к трудноуловимым багам. Например, вы в проекте зависите от какой-нибудь библиотеки A транзитивно зависящей от библиотеки B версии X. В spring-boot-starter-parent прописана B версии Y (отсутствие прямой и/или обратной совместимости между версиями X и Y), на которой A ломается. Увидев такое безобразие вы прописываете в dependencies
библиотеку B версии X. Таким нехитрым образом можно получить крайне неприятный и относительно трудноуловимый баг, который вылезет в недрах того же spring boot'а или его компонентов.0
Можете описать один-два таких момента? А то я как раз выбрал Spring Boot, как раз написал Hello World и теперь вот прочитал ваш коммент и загрустил.
0
Когда есть опыт работы со спрингом, особых проблем с кастомизацией не возникает. Если хочется что-то настроить под себя — просто смотришь исходники соответствующего класса автоконфигурации, и либо переделываешь его с нуля, либо меняешь соответствующие бины. Но если опыта нет, то будет тяжело во всём этом разбираться.
Пара неприятных проблем, которые мне встречались:
При сабмите www-url-encoded формы кодировка определялась как ISO-8859-1. Быстро вылечилось заменой томката на джетти. Потом выяснил, что можно пофиксить добавлением соответствующего фильтра в цепочку spring security.
Пара библиотек отказалась работать со вложенными jar'ами — пришлось дописать лишнюю сотню строк кода.
Thymeleaf под себя дорабатывать довольно трудно, но это с непривычки и к спрингу мало относится.
Пара неприятных проблем, которые мне встречались:
При сабмите www-url-encoded формы кодировка определялась как ISO-8859-1. Быстро вылечилось заменой томката на джетти. Потом выяснил, что можно пофиксить добавлением соответствующего фильтра в цепочку spring security.
Пара библиотек отказалась работать со вложенными jar'ами — пришлось дописать лишнюю сотню строк кода.
Thymeleaf под себя дорабатывать довольно трудно, но это с непривычки и к спрингу мало относится.
0
>Если хочется что-то настроить под себя — просто смотришь исходники соответствующего класса автоконфигурации, и либо переделываешь его с нуля
>переделываешь
>лечилось заменой
>дописать
в этом весь спринг бут, спасибо
>переделываешь
>лечилось заменой
>дописать
в этом весь спринг бут, спасибо
0
В этом весь %любойфреймворк%.
По большому счёту, бут — это набор стартовых конфигов. Править и переделывать их — естественная задача. А чтобы их править, надо для начала изучить спринг DI, WebMvc, Security, Data и кучу всего прочего, что бут настраивает по умолчанию.
Вы до этого со спрингом много работали? «Чехарда с xml и аннотациями» вообще не должна возникать — в новом проекте должно использоваться либо то, либо другое.
По большому счёту, бут — это набор стартовых конфигов. Править и переделывать их — естественная задача. А чтобы их править, надо для начала изучить спринг DI, WebMvc, Security, Data и кучу всего прочего, что бут настраивает по умолчанию.
Вы до этого со спрингом много работали? «Чехарда с xml и аннотациями» вообще не должна возникать — в новом проекте должно использоваться либо то, либо другое.
0
почему смешанное использование xml и аннотаций это чехарда? и почему либо одно либо другое?
0
Чехарда — это цитата из первого комментария ветки — поленился правильно выделить.
Смешивание разных способов конфигурации почти всегда усложняет структуру приложения. Поначалу кажется, что «а ладно, здесь я проще добавлю xml с нэймспейсом», а через год-другой там уже десятки файлов от разных разработчиков друг друга дёргают. Это в худшем случае, конечно, но всё равно лишний риск.
Смешивание разных способов конфигурации почти всегда усложняет структуру приложения. Поначалу кажется, что «а ладно, здесь я проще добавлю xml с нэймспейсом», а через год-другой там уже десятки файлов от разных разработчиков друг друга дёргают. Это в худшем случае, конечно, но всё равно лишний риск.
0
со спрингом работал много
когда я попытался сделать standalone rest сервер который бы отдавал не только crud, но и немного логики, я был сильно огорчён тем, что всё снова пришлось делать руками, и тогда нет разницы, использовать spring boot или, например, jersey
когда я попытался сделать standalone rest сервер который бы отдавал не только crud, но и немного логики, я был сильно огорчён тем, что всё снова пришлось делать руками, и тогда нет разницы, использовать spring boot или, например, jersey
0
У меня Thymeleaf в одном из проектов. Дорабатывался легко.
Да с автоконфигурациями можно наступить на грабли, если нужно что-то конкретно переделать, но в таком случае, лучше отключить нужную автоконфигурацию и написать свою с нуля.
Да с автоконфигурациями можно наступить на грабли, если нужно что-то конкретно переделать, но в таком случае, лучше отключить нужную автоконфигурацию и написать свою с нуля.
0
UFO just landed and posted this here
Его, собственно, и не любят за:
— многословность,
— неудобство редактирования без специализированного редактора.
— многословность,
— неудобство редактирования без специализированного редактора.
0
Кстати, на одном видео с jug.ru был показан бенчмарк, в котором java-конфигурация загружалась медленнее, чем xml.
Мне еще нравится xml тем, что при необходимости, можно залезть в war-ку, и в xml законфигурировать разные параметры, и все это заработает без перекомпиляции. Незаслуженно недооценивают xml (те, кто его хаят).
Мне еще нравится xml тем, что при необходимости, можно залезть в war-ку, и в xml законфигурировать разные параметры, и все это заработает без перекомпиляции. Незаслуженно недооценивают xml (те, кто его хаят).
+2
Ничего страшного. Временем загрузки можно и пожертвовать. В джава конфигах еще и проксей по-моему много создается, поэтому вызов вашего метода тоже замедляется. Мне нравится практика скрещивания описаний, что-то в xml, что-то аннотациями. В последнее время смотрю уже на groovy конфиг. Скорее бы идея с ним научилась нормально работать)
+1
Есть видео, как за 20 минут сделать минимальный проект с базой данных на scala и play www.youtube.com/watch?v=eNCerkVyQdc
Есть аналогичные про python+django, есть про GWT, vaadin и много других. А вот видео про то, как сделать чего-то осязаемое на spring за 10-20 минут или даже за час я не нашёл, хоть и старался. О чём-то это говорит.
Есть аналогичные про python+django, есть про GWT, vaadin и много других. А вот видео про то, как сделать чего-то осязаемое на spring за 10-20 минут или даже за час я не нашёл, хоть и старался. О чём-то это говорит.
0
куплю книжку «Spring Framework For Dummies» — добавлю в коллекцию к «Java Programming. 24-Hour Trainer»
0
Видел как-то в официальном блоге Spring.io:
Screencast: How to create a RESTful app in five minutes or less
Screencast: How to create a RESTful app in five minutes or less
0
В случае thymeleaf вам нужно подрубить только зависимость и написать main класс. Минимальный проект выходит за 1 минуту. Хотя это смотря, что считать «минимальным проектом»
0
Просто Spring это не игрушка на 20 минут. Это, безусловно, сложный инструмент, но одновременно и очень мощный, с огромными возможностями. Ведь на Boeing тоже не учат летать за 20 минут
+1
Пишу уже второй небольшой проект (на буте + ангуляре) в свободное от работы время. Когда искал на что бы пересесть кроме приевшегося jee стека, наткнулся на спринг бут, и остался очень доволен. Используя только spring.io с документашками, поднял всё что мне было нужно и без особых проблем. Самый большой затык был разве что в data rest. Долго не мог понять почему не получалось сменить base url для рестов. В остальном вещь просто отличная. Если добавить генерилку jpa сущностей, то по уровню spring boot можно сравнить с обычным скаффолдингом в рельсах.
0
Используем Spring Boot в своих проектах, в целом удобно, но кастомизация — боль.
Однако для своих маленьких проектов он удобен. Если надо что-то быстро запустить — лучший выбор.
Лично для меня, само собой.
Однако для своих маленьких проектов он удобен. Если надо что-то быстро запустить — лучший выбор.
Лично для меня, само собой.
0
А уточните в чем конкретно боль, возможно уже пройденные грабли.
0
Довольно сложно настроить под себя. Он уже идет с набором библиотек и стандартных конфигов, если надо что-то свое, то настройка превращается в исключение зависимостей и выключение некоторых функций, плюс громоздкие конструкции вида
или
@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);
}
});
}
}
}
};
}
0
Не знаю насколько оправдано использование Spring Boot. Для реального проекта не принципиально, потрачу ли я десять минут на подключение зависимостей и написание конфигурации. Также не могу понять полезность spring-boot:run если всю жизнь можно было пускать embedded Jetty container из main(). В большом проекте с кучей профайлов и зависимостей сведется на нет все преимущества автоконфигурирования.
0
Простите, не нашел ссылки на оригинал
-1
Sign up to leave a comment.
Стоит ли использовать Spring Boot в вашем следующем проекте?