Здравствуйте, Аноним931, Вы писали:
А>Гугление по текущему положению вещей дает примерно такой общий ответ: "Spring был замечательной и действительно полезной вещью те многие годы, пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все преимущества перед ней".
Так пишут апологеты JEE. JEE много лет имеет одну никак не решаемую проблему. Она называется Corner Cases. Если чего-то нет в спецификации, то это реализуется только средствами вендора либо вовсе через задницу. Эта проблема никак не решена и решена не будет по причине того чем JEE является.
А>Это действительно так, или адепты Java EE приукрашивают ситуацию?
Приукрашивают. На JEE стало, действительно, проще писать, но геморроя меньше не стало. Где-то сопли из старых спецификаций тянутся. Где-то просто что-то не продумали.
В результате если у тебя WebLogic, то ты счастлив и всеми руками за JEE. А если у тебя GlassFish, то ты каждую неделю пасешься в его багтрекере.
А>Вот возьмем некий абстрактный новый проект на современной платформе: Wildfly 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. Имеет ли смысл задумываться о том, тыкать ли туда Spring?
На вкус и цвет. Всё очень сильно зависит от того какой именно набор технологий нужен. На чем фронт-энд? Нужна ли MQ? Достаточно ли JPA API?
On 22.09.2015 11:56, Dziman wrote: > h> Туда — нет. За последние годы сделали несколько крупных проектов на базе > h> JEE6/7 (бэк, сервера приложений — jboss/wildfly и weblogic) + AngularJS > h> (фронт), процесс очень понравился. Сейчас занимаемся в числе прочего > h> доработкой одного проекта, сделанного на Spring+Tomcat, он нравится > h> определённо меньше. > > А чем конкретно меньше нравится?
Тем, что всё то же самое, что есть в JEE, там пишется другими
аннотациями — reinvent a wheel несколько печалит, непонятно почему бы не
реализовать просто соответствующие части jee спек.
Ну и там Spring MVC использован, по сравнению с веб-клиентом на ангуляре
сложнее отделять фронтэнд. Хотя это непосредственно к спрингу отношения
не имеет.
On 22.09.2015 09:45, "Аноним931" wrote: > Гугление по текущему положению вещей дает примерно такой общий ответ: > "Spring был замечательной и действительно полезной вещью те многие годы, > пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким > говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все > преимущества перед ней". > Это действительно так, или адепты Java EE приукрашивают ситуацию? Вот > возьмем некий абстрактный новый проект на современной платформе: Wildfly > 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. > Имеет ли смысл задумываться о том, тыкать ли туда Spring?
Туда — нет. За последние годы сделали несколько крупных проектов на базе
JEE6/7 (бэк, сервера приложений — jboss/wildfly и weblogic) + AngularJS
(фронт), процесс очень понравился. Сейчас занимаемся в числе прочего
доработкой одного проекта, сделанного на Spring+Tomcat, он нравится
определённо меньше.
С другой стороны приложения, не требующие контейнера, (микросервисы)
пишем с использованием спринга (spring boot), тоже представляется
достаточно удобным.
Здравствуйте, hrensgory, Вы писали:
H>В том проекте, о котором я упоминал, используется более классический H>Spring MVC (то есть там есть V, рендерящийся на сервере). Наверняка H>можно и Spring MVC сделать чисто REST сервером, хотят тут встаёт вопрос
Когда делали Spring REST обнаружили, что он выходит сплошной копипастой Spring MVC. Поэтому просто добавили всё недостающее в Spring MVC
Гугление по текущему положению вещей дает примерно такой общий ответ: "Spring был замечательной и действительно полезной вещью те многие годы, пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все преимущества перед ней".
Это действительно так, или адепты Java EE приукрашивают ситуацию? Вот возьмем некий абстрактный новый проект на современной платформе: Wildfly 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. Имеет ли смысл задумываться о том, тыкать ли туда Spring?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
H>Ну и там Spring MVC использован, по сравнению с веб-клиентом на ангуляре сложнее отделять фронтэнд
О! Вот этот пункт мне лично очень интересен. В гугле находятся сотни восторженных отзывов именно о связке Spring MVC + AngularJS ("...не могу себе теперь представить делать проект как-то по-другому"). А ты противопоставляешь их. Можешь пояснить? А то я ни в первом, ни во втором ни бум-бум.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
DV>Получается, что принцип JEE — спецификация отдельно, вендор отдельно — не работает? Т.е. с WebLogic просто так не уйти на JBoss?
Да какой JBoss. С Weblogic проблематично
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
B>В результате если у тебя WebLogic, то ты счастлив и всеми руками за JEE. А если у тебя GlassFish, то ты каждую неделю пасешься в его багтрекере.
А если Wildfly?
B>Всё очень сильно зависит от того какой именно набор технологий нужен
Бэк-энд: фоновые задачи типа "возьми файл с FTP, вытащи из него интересную инфу, запиши ее в БД, в случае неудачи сообщи по мейлу админу". Реализация собственно интерфейсов передачи данных (FTP, мейл и т.д.) в данном контексте неинтересна, она у нас для 99% случаев уже есть и работает. Вопрос стоит о том, чтобы все это красиво запихать в новую платформу.
Фронт-энд: администрирование этих самых фоновых задач.
B>На чем фронт-энд?
Его нет еще совсем, равно как и ограничений по технологиям для его реализации.
B>Нужна ли MQ?
WebSphere MQ? Нет. Или очереди вообще? JMS нужна, да.
B>Достаточно ли JPA API?
Да.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А> Имеет ли смысл задумываться о том, тыкать ли туда Spring?
Я думаю однозначно тебе никто не ответит никогда. Может тебе spring подойдет, может dropwizard может еще чего. Я бы при выборе проекты на гитхабе поискал, сделал бы форк на поиграться, потом уже думал.
Здравствуйте, hrensgory, Вы писали:
h> Туда — нет. За последние годы сделали несколько крупных проектов на базе h> JEE6/7 (бэк, сервера приложений — jboss/wildfly и weblogic) + AngularJS h> (фронт), процесс очень понравился. Сейчас занимаемся в числе прочего h> доработкой одного проекта, сделанного на Spring+Tomcat, он нравится h> определённо меньше.
A>Я думаю однозначно тебе никто не ответит никогда. Может тебе spring подойдет, может dropwizard может еще чего. Я бы при выборе проекты на гитхабе поискал, сделал бы форк на поиграться, потом уже думал.
Ну я, собственно, и не ожидаю (пока) однозначного ответа "да"/"нет". Хотелось бы для начала услышать мнения именно к моей "обобщенной" постановке вопроса. Т.е. хотелось бы начинать опыты сразу на тех технологиях/библиотеках/фреймворках, которые мне с некой относительно высокой вероятностью подойдут, и не тратить время на остальные.
Понимаю — все это пока звучит очень пространно. Но конкретнее в данный момент просто не получается
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Ну я, собственно, и не ожидаю (пока) однозначного ответа "да"/"нет". Хотелось бы для начала услышать мнения именно к моей "обобщенной" постановке вопроса. Т.е. хотелось бы начинать опыты сразу на тех технологиях/библиотеках/фреймворках, которые мне с некой относительно высокой вероятностью подойдут, и не тратить время на остальные. А>Понимаю — все это пока звучит очень пространно. Но конкретнее в данный момент просто не получается
Смотри. Есть JEE спецификация. Она состоит из требований и API для разных решений — UI, работа с БД, очередь сообщений, бизнес-логика и т.п.
Когда ты берешь JEE сервер, то ты получаешь и пачку фреймверков под каждое из этих решений. Opensource сервера это вообще сборная солянка из opensource решений с API в форме JEE.
Spring же позволяет выбрать каждый фреймверк независимо, по желанию, и интегрироваться с ним.
On 22.09.2015 14:48, "Аноним931" wrote: > H>Ну и там Spring MVC использован, по сравнению с веб-клиентом на > ангуляре сложнее отделять фронтэнд > > О! Вот этот пункт мне лично очень интересен. В гугле находятся сотни > восторженных отзывов именно о связке Spring MVC + AngularJS > (/"...не могу себе теперь представить делать проект как-то > по-другому"/). А ты противопоставляешь их. Можешь пояснить? А то я ни в > первом, ни во втором ни бум-бум.
AngularJS — это чистый JS, ему всё равно что на сервере. В наших JEE
проектах на сервере REST на JAX-RS (благо он теперь тоже часть JEE),
весь хтмл рендерится ангуляром на клиенте. Это даёт возможность полного
отделения фронта от бэка, так что у чистых фронтэндщиков, которые
работают с внешним видом приложения и клиентским кодом, на машинах
вообще нет никаких томкатов/веблоджиков, им не надо ничего
собирать/деплоить и т.п. что положительно сказывается на
производительности труда и финансовых результатах проектов.
В том проекте, о котором я упоминал, используется более классический
Spring MVC (то есть там есть V, рендерящийся на сервере). Наверняка
можно и Spring MVC сделать чисто REST сервером, хотят тут встаёт вопрос
— а зачем же тогда V в этом MVC?
Здравствуйте, Аноним931, Вы писали:
А>Гугление по текущему положению вещей дает примерно такой общий ответ: "Spring был замечательной и действительно полезной вещью те многие годы, пока Java ЕЕ была непродуманным неудобным малофункциональным громоздким говном. Сейчас Java ЕЕ прекрасна, и Spring потерял практически все преимущества перед ней". А>Это действительно так, или адепты Java EE приукрашивают ситуацию? Вот возьмем некий абстрактный новый проект на современной платформе: Wildfly 9, Java 8, JEE 7. Много бэк-энда и простенькaя админка как фронт-энд. Имеет ли смысл задумываться о том, тыкать ли туда Spring?
Application server — ад. Он в принципе никому не нужен, кроме тех кто его продает. Самая большая проблема — появляются зависимости, которые само приложение никак не определяет. Соответственно, если надо их поменять, то не получится, надо что-то сделать не так как как в аппликейшн сервере — тоже проблема. Потом, если честно, то приложение, на мой взгляд, смотрится довольно забавно, когда требует установки какого-то монстра всего-лишь для того, чтобы общаться с базой и показывать html.
Спринг же более гибкая альтернатива, дает выбор что тянуть а что нет. Не нравится то, что в спринге — вытягивай с наружи. Я бы ваще guice взял, все остальное — библиотеками.
On 22.09.2015 16:19, Blazkowicz wrote:
> H>В том проекте, о котором я упоминал, используется более классический > H>Spring MVC (то есть там есть V, рендерящийся на сервере). Наверняка > H>можно и Spring MVC сделать чисто REST сервером, хотят тут встаёт вопрос > Когда делали Spring REST обнаружили, что он выходит сплошной копипастой > Spring MVC. Поэтому просто добавили всё недостающее в Spring MVC
Вполне по-моему логично, непонятно только чего бы заодно не реализовать
спеку JAX-RS здесь.
Кстати внутри того же веблоджика дофига перепакованного спринга.
Здравствуйте, hrensgory, Вы писали:
H>Вполне по-моему логично, непонятно только чего бы заодно не реализовать H>спеку JAX-RS здесь.
Заодно
In January 2011 the JCP formed the JSR 339 expert group to work on JAX-RS 2.0.[2] The main targets are (among others) a common client API and support for Hypermedia following the HATEOAS-principle of REST. In May 2013, it reached the Final Release stage
H>Кстати внутри того же веблоджика дофига перепакованного спринга.
До покупки Ораклом у них и в мануале было написано — используйте Spring где только можете.
SK>Application server — ад. Он в принципе никому не нужен, кроме тех кто его продает.
Я могу себе представить, что AS являются очень даже подходящим решением для больших фирм, у которых на серверах крутится много разного софта от многих разных поставщиков. Т.е. некий дополнительный слой стандартизации рантайма.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Я могу себе представить, что AS являются очень даже подходящим решением для больших фирм, у которых на серверах крутится много разного софта от многих разных поставщиков. Т.е. некий дополнительный слой стандартизации рантайма.
Работая уже много лет в тех "больших фирмах" наблюдаю всё меньше и меньше монстров типа Web Sphere/Web Logic (уже несколько лет не встречал, если честно), большие приложения стараются сделать в виде сервисов используя Tomcat и Jetty. Спринг используется везде где только можно.
Здравствуйте, Antei, Вы писали:
A>Здравствуйте, Аноним931, Вы писали:
А>>Я могу себе представить, что AS являются очень даже подходящим решением для больших фирм, у которых на серверах крутится много разного софта от многих разных поставщиков. Т.е. некий дополнительный слой стандартизации рантайма.
A>Работая уже много лет в тех "больших фирмах" наблюдаю всё меньше и меньше монстров типа Web Sphere/Web Logic (уже несколько лет не встречал, если честно), большие приложения стараются сделать в виде сервисов используя Tomcat и Jetty. Спринг используется везде где только можно.
Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
Здравствуйте, Transformerrr, Вы писали:
T>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
Получается, что принцип JEE — спецификация отдельно, вендор отдельно — не работает? Т.е. с WebLogic просто так не уйти на JBoss? Не холивара ради, практический интерес.
On 24.09.2015 15:08, dya-victor wrote:
> Получается, что принцип JEE — спецификация отдельно, вендор отдельно — > не работает? Т.е. с WebLogic просто так не уйти на JBoss? Не холивара > ради, практический интерес.
Мы переходили в рамках JEE6 с WL на JBoss (в обоих направлениях).
Были мелкие нюансы с конфигурацией jax-rs, в остальном — всё работает.
Здравствуйте, dya-victor, Вы писали:
DV>Здравствуйте, Transformerrr, Вы писали:
T>>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
DV>Получается, что принцип JEE — спецификация отдельно, вендор отдельно — не работает? Т.е. с WebLogic просто так не уйти на JBoss? Не холивара ради, практический интерес.
По крайней мере на Java EE 5 — не работало. Собирались разные пекеджи под каждый апп сервер. Были проблемы с EJB lookup. В следующей версии ЕЕ это должно быть пофикшено, возможно на более новых версиях счастье все ближе
Здравствуйте, Transformerrr, Вы писали:
T>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
Кроме смены имени, корректировке подверглись цели и задачи проекта: WildFly сфокусирован на быстром внедрении инноваций и продвижении новых технологий, в то время как коммерческий продукт JBoss Enterprise Application Platform позиционируется как интегрированная, полностью протестированная и сертифицированная платформа Java EE. В качестве основной области использования WildFly рассматривается разработка и быстрое внедрение прототипов. Принципы разработки и распространения сервера приложений остались неизменны, продукт как и раньше является полностью свободным, бесплатным и общедоступным, а также выступает в роли upstream-проекта для коммерческого продукта JBoss Enterprise.
Компания Oracle выпустила открытый сервер приложений GlassFish Server Open Source Edition 4.1, предоставляющий полную реализацию спецификации Java EE 7 (Java Platform, Enterprise Edition 7), как в форме web профиля (Java EE 7 Web Profile), так и полного профиля (Java EE 7 Full Platform). Включение выражения "Open Source Edition" в название продукта сигнализирует о прекращении его коммерческой поддержки, о чём было заявлено Oracle в ноябре прошлого года. Пользователям, которым требуется коммерческая поддержка, рекомендовано использовать продукт Oracle WebLogic Server. Код GlassFish распространяется под двумя лицензиями: CDDL v1.0 и GPL v2.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Transformerrr, Вы писали:
T>>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
ZEN>Так ведь совсем недавно : ZEN>
ZEN>Кроме смены имени, корректировке подверглись цели и задачи проекта: WildFly сфокусирован на быстром внедрении инноваций и продвижении новых технологий, в то время как коммерческий продукт JBoss Enterprise Application Platform позиционируется как интегрированная, полностью протестированная и сертифицированная платформа Java EE. В качестве основной области использования WildFly рассматривается разработка и быстрое внедрение прототипов. Принципы разработки и распространения сервера приложений остались неизменны, продукт как и раньше является полностью свободным, бесплатным и общедоступным, а также выступает в роли upstream-проекта для коммерческого продукта JBoss Enterprise.
ZEN>Компания Oracle выпустила открытый сервер приложений GlassFish Server Open Source Edition 4.1, предоставляющий полную реализацию спецификации Java EE 7 (Java Platform, Enterprise Edition 7), как в форме web профиля (Java EE 7 Web Profile), так и полного профиля (Java EE 7 Full Platform). Включение выражения "Open Source Edition" в название продукта сигнализирует о прекращении его коммерческой поддержки, о чём было заявлено Oracle в ноябре прошлого года. Пользователям, которым требуется коммерческая поддержка, рекомендовано использовать продукт Oracle WebLogic Server. Код GlassFish распространяется под двумя лицензиями: CDDL v1.0 и GPL v2.
ZEN>
Я писал о тенденции в нашей организации, причем в инфраструктуре заказчиков — крупных компаний. Вообщем, гласфиш конечно развивается.
Здравствуйте, Transformerrr, Вы писали:
T>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic был бы нужен только тем кто его продает
On 25.09.2015 11:07, Alex912 wrote: > T>Обратный опыт — приложение на сервлетах и JSP на Tomcat было > переписано на java EE и деплоится на WebLogic. Причем чем дальше — тем > больше WebLogic, JBOSS ушел в сад, гласфиш похоже будет следующим. > Впрочем, если бы стояла цель удешевить эксплуатацию софта — то WebLogic > был бы нужен только тем кто его продает > > Что-то сразу вспомнилось https://www.youtube.com/watch?v=cPXTozVjSHo
Очень хороший доклад — все стереотипы и глупости про JEE в одном
флаконе. Одно время даже хотел снять какой-нибудь обратный ролик, типа
"Как нам спасти Codeborne", но задора чё-то не хватило
Здравствуйте, Transformerrr, Вы писали:
T>Обратный опыт — приложение на сервлетах и JSP на Tomcat было переписано на java EE и деплоится на WebLogic.
Не, ну если говорить про JSP и сервлеты — то конечно, Java EE однозначно лучше. Но при чём здесь Spring? JSP и сервлеты — это было актуально где-то лет 10-15 назад. Современный Spring (я имею в виду — как это обычно делают сейчас) — это сплошной REST с отдачей UI на откуп клиенту (javascript/android/whatever). И да, я наблюдаю ровно обратную картину — всё больше проектов на Spring Framework, и всё меньше на Java EE, всё у большего количества заказчиков уже работают решения на Spring + Tomcat (или даже Jetty), причём включая традиционно консервативных заказчиков, типа банков и т.д.
:
