Java EE 6 против стека Spring 3 [закрыто]

90

Сейчас начинаю новый проект. Приходится выбирать технологии. Мне нужно что-то легкое, поэтому никаких EJB или Seam. С другой стороны, мне нужны JPA (Hibernate или альтернатива) и JSF с IceFaces.

Считаете ли вы, что такой стек в Spring 3, развернутый на Tomcat, является хорошим выбором? Или веб-приложение Java EE 6 могло быть лучше? Боюсь, что Java EE 6 - это новая технология, еще недостаточно документированная. Tomcat кажется проще в обслуживании, чем Glassfish 3.

Каково твое мнение? Есть ли у вас опыт?

Петр Гвязда
источник
8
Я бы выбрал Primefaces.org вместо IceFaces, если вам нужен свет. Это намного быстрее и компактнее API.
Шервин Асгари,
1
На данный момент JEE6 предоставляет только Glassfish. Resin медленно внедряет веб- профиль JEE6 , которого вам может хватить в зависимости от того, что вам нужно.
Торбьёрн Равн Андерсен
3
@ Thorbjørn Вы можете использовать веб-профиль GlassFish v3, если вам нужен только веб-профиль.
Паскаль Тивент,
@Pascal, это было подробно описано, что скоро появится альтернатива Glassfish, чтобы получить JEE6, если вы можете жить с веб-профилем (я могу), не говоря уже о Glassfish.
Thorbjørn Ravn Andersen
@ Thorbjørn Я забыл удалить @ Thorbjørn :) Комментарий был предназначен для OP, который, похоже, предполагает использование GFv3 с полным стеком как единственный вариант.
Паскаль Тивент,

Ответы:

101

Мне нужно что-то легкое, поэтому никаких EJB или Seam.

Не могли бы вы объяснить, что делает EJB тяжелыми после EJB3? Вы понимаете, что мы уже не в 2004 году? Я действительно хотел бы прочитать ваше определение света и ваши аргументы (и я с удовольствием обновлю свой ответ, потому что я почти уверен, что у меня есть несколько веских вещей).

С другой стороны, мне нужны JPA (Hibernate или альтернатива) и JSF с IceFaces.

Веб-профиль Java EE 6, который включает JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... идеально подойдет для этого, и вы можете использовать веб-профиль GlassFish v3 для запуска приложения, созданного с помощью веб-профиля Java EE 6 .

Как вы думаете, такой стек в Spring 3, развернутый на Tomcat, - хороший выбор? Или веб-приложение Java EE 6 могло быть лучше?

Что ж, мне нравится идея запускать мой код на непроприетарной платформе (Java EE), а не в проприетарном контейнере (Spring). И я думаю, что Java EE 6 достаточно хороша (и это эвфемизм, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI пипец). Обратите внимание, что я был скептиком JSF, но я взглянул еще раз: JSF 2.0 с CDI настолько отличается, что я даже не могу сравнивать. И если вы не смотрели на CDI, позвольте мне сказать вам, что он потрясающий.

Боюсь, что Java EE 6 - это новая технология, еще недостаточно документированная.

Мне кажется, что Java EE хорошо документирован. Звучит как бесплатное требование. И, хотите верьте, хотите нет, но Spring становится все сложнее, а Java EE - проще.

Tomcat кажется проще в обслуживании, чем Glassfish 3.

Вы что-то пробовали? Сталкивались ли вы с какой-либо конкретной проблемой? Опять же, это звучит как бесплатное требование.

Паскаль Тивент
источник
2
Я сразу после того, как оценил большой проект, разработанный с EJB3.0 + Seam на JBoss с Drools, GraniteDS и другими. Я согласен Шов качает! Но я потратил 50% разработки на повторное развертывание, перезапуск серверов, ошибки развертывания, очистку временных каталогов и т. Д. С другой стороны, производительность JBoss Tools была очень низкой (я действительно имею в виду - ctrl + пробел и 10 секунд зависания) Это действительно отговаривает меня использовать JEE6 который выглядит как заимствованный из фреймворка Seam. Что касается сервера, то я не хочу думать о пулах conecion, jndi, jms, jmx, ear deplyment. Мне нужно что-нибудь, чтобы поставить WAR и запустить его за секунды.
Петр Гвязда,
6
@peperg Gaving King является лидером спецификации CDI (Weld - это RI), поэтому вы найдете сходство между Seam и CDI. Но CDI! = Шов, Java EE 6! = Шов, ваше восприятие неверно. Может быть, попробуйте GlassFish v3 Web Profile, вы будете удивлены (и после определения пула соединений беспокоиться не о чем).
Паскаль Тивент
8
Что такое люди говорят, что EJB тяжелые? Я использую EJB v3.1, и это просто аннотированные pojos. Когда они говорят «тяжелые», они имеют в виду производительность или что?
arg20
13
@ arg20 - Это действительно большой вопрос, и Паскаль справедливо просит объяснить, что означает термин «тяжелый» (или «легкий») в этом контексте. Скорее всего, это остаток старой вражды между Spring и EJB. Вначале EJB1 & 2 были концептуально тяжелыми. Чрезмерный упор на удаленное взаимодействие и компоненты с отслеживанием состояния, смехотворно подробный дескриптор развертывания XML и совершенно безумное количество требуемых интерфейсов для реализации сделали им очень плохую репутацию. С появлением EJB3 (2006) это полностью изменилось, но люди, которые покинули EJB в 2004 году ради Spring, иногда все еще думают, что это 2004 год, а EJB2 - самый последний.
Arjan Tijms,
7
Обратите внимание, что на странице Spring о программе написано: «Мы считаем, что: J2EE должен быть проще в использовании». Обратите внимание, что они используют термин «J2EE», а не «Java EE», которое было правильным названием с момента выпуска Java EE 5 (я думаю). Это многое о них говорит ...
Витор Э. Сильва Соуза
32

Я не использовал JavaEE6.

Однако все предыдущие версии JavaEE и EJB меня достаточно сильно избили, и я не буду доверять им, пока они не утвердятся в качестве стандарта де-факто, а не только стандарта де-юре. Прямо сейчас Spring по-прежнему является стандартом де-факто.

Обмани меня один раз, позор вам. Обмани меня дважды, позор мне. Обмани меня трижды, EJB.

Некоторые будут утверждать, что Spring проприетарный. Я бы сказал, что реализации спецификаций JavaEE производителями были такими же проприетарными, если не больше.

Недавно я претерпел серьезное преобразование, переместив несколько Java-приложений с JBoss на Weblogic. Все приложения Spring / Hibernate были перенесены без каких-либо модификаций, поскольку в них были встроены все необходимые библиотеки. Перенос всех приложений, использующих JPA, EJB и JSF, был катастрофой. Незначительные различия в интерпретации JPA, EJB и JSF между серверами приложений вызвали всевозможные неприятные ошибки, исправление которых потребовалось целую вечность. Даже такая простая вещь, как именование JNDI, совершенно различалась между серверами приложений.

Spring - это реализация. JavaEE - это спецификация. Это ОГРОМНАЯ разница. Я бы предпочел использовать спецификацию, ЕСЛИ спецификация была на 100% герметичной и не давала абсолютно никакого пространства для маневра в способе реализации этой спецификации поставщиками. Но спецификация JavaEE никогда не была такой. Может быть, JavaEE6 более герметичен? Я не знаю. Чем больше вы можете упаковать в WAR и чем меньше вы зависите от библиотек AppServer, тем более портативным будет ваше приложение, и это, в конце концов, является причиной того, что я использую Java, а не Dot-NET.

Даже ЕСЛИ бы спецификация была герметичной, было бы неплохо иметь возможность обновить сервер приложений без необходимости обновлять все мои технологические стеки во всех моих приложениях вместе с ним. Если я хочу выполнить обновление с JBoss 4.2 до JBoss 7.0, я должен учесть влияние новой версии JSF на все мои приложения. Мне не нужно учитывать влияние на мои приложения Spring-MVC (или Struts).

Стакан
источник
1
Собственно, это отличное рассуждение.
Palesz
1
Я согласен с этим рассуждением, многие проблемы, с которыми я столкнулся, были связаны с зависимостями от реализации спецификации в контейнере. Значительно меньше боли от встроенных библиотек. Трудно спорить, если не считать философских предпочтений спецификации.
Питер Портер
Замечательное рассуждение. Однако это ваш опыт даже после JEE 6? Я понимаю, что реализация спецификаций сервера приложений все еще может быть проблемой - следовательно, та же спецификация, реализованная на сервере приложений 1, может быть простой и эффективной, но не для сервера приложений 2
Сумья
1
+1. Кроме того, сервер приложений изменяется по расписанию операций, где spring / hibernate находится под контролем разработчиков. в среде большой компании обновление сервера приложений является гораздо более важным делом.
Натан Хьюз
Я не совсем понял Dot-Net. Он является такой же частной собственностью, как и Spring, и разработан одним поставщиком, которым является Microsoft. Можно это объяснить?
user1339260
23

Неважно. Java EE 6 достаточно хорош, и из-за наличия профилей он не «тяжелый» - вы просто будете использовать веб-профиль.

Лично я предпочитаю Spring. Но у меня заканчиваются рациональные аргументы против Java EE 6 :)

(Как мне напомнил комментарий - вы можете попробовать RichFaces , а также ICEfaces и / или PrimeFaces - в зависимости от того, какие компоненты вам нужны).

Божо
источник
1
Возникает вопрос: «Имеет ли смысл использовать полнофункциональный сервер приложений Glassfish, просто используя веб-профиль»?
Петр Гвязда,
1
@peperg Используйте веб-профиль GlassFish v3, если вам просто нужен веб-профиль, см. мой ответ.
Паскаль Тивент,
Я разместил здесь несколько аргументов stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/… , скорее взятых из точки зрения «как внедрить это в производство». Так что, возможно, это немного пополнит ваш запас аргументов.
Оливер Дротбом,
@peperq, JBoss 6 был выпущен в праздничные дни.
Торбьорн Равн Андерсен
17

Недавно одно из моих клиентских заданий включало оценку Spring Stack Vs Custom framework stack и Java EE Standards. После месяца оценки и создания прототипа я был не просто счастлив, но и потрясен набором функций Java EE 6. Для любой новой архитектуры «корпоративного» проекта в 2011 году и в будущем я бы выбрал Java EE 6 и потенциальные расширения, такие как Seam 3 или предстоящий проект расширений Apache JSR299. Архитектура Java EE 6 оптимизирована и включает в себя лучшее из многих идей с открытым исходным кодом, появившихся за последние несколько лет.

Рассмотрите следующие возможности из коробки: управление событиями, контексты и DI, перехватчики, декораторы, веб-сервисы RESTful, интегрированное тестирование с встраиваемым контейнером, безопасность и многое другое.

Большинство моих результатов опубликовано в моем блоге объясняются ключевые концепции Java EE 6, которые могут быть вам полезны.

Конечно, жестких правил выбора фреймворка не существует. Java EE 6 может быть хорошо раздута для более простых «веб-сайтов», которые не требуют богатого диалогового состояния сеанса. Вы можете также выбрать Grails или Play! Фреймворк. Но для диалоговых веб-приложений я не вижу лучшего аргумента, почему Java EE 6 не подходит.

при
источник
Java EE 6 просто чертовски медленный, веб-профиль glassfish и glassfish просто очень медленный, чтобы начать сравнивать их с причалом / tomcat / чем-то еще. Тестирование встраиваемого контейнера тоже очень медленное.
Palesz
15

Теперь, спустя некоторое время, у меня появился опыт работы со стеками:

  • Java EE 5 + шов + гранитDS + Flex
  • Весна 3 + Ваадин (на GWT)
  • Spring 3 + JSF 2.0 (PrimeFaces)

Мои выводы:

  • Spring 3 намного проще, чем Seam (почти Java EE 6), и работает на Tomcat и Jetty! (Причал для разработки с плагином maven - это трасса).
  • Я люблю Flex (на самом деле я был разработчиком Flex в течение долгого времени, поэтому я предвзято), и если вам нужен богатый интерфейс и вы можете купить FlashBuilder, используйте его, но используйте его, с бэкэнд Spring + GraniteDS или BlazeDs. Если вы не можете купить FlashBuilder, не тратьте зря время.
  • Ваадин великолепен !. Процесс разработки проще, чем Flex, но вы можете легко создавать многофункциональные приложения без беспорядка HTML. Вы не будете писать одну строчку на JS. Вам просто нужен CSS (во Flex он вам тоже нужен). Итак, если интерфейс вашего приложения будет вести себя как настольное приложение, и вы не можете (или не хотите) использовать Flex - используйте Vaadin. Предупреждение! У Vaadin большие накладные расходы на JS для браузера.
  • Если вы создаете более простое приложение, подобное веб-сайту, используйте JSF2.0 (с бэкендом Spring, как указано выше). Вам нужно будет бороться с HTML (я его ненавижу), и создание богатого интерфейса будет сложнее, чем Vaadin (особенно макеты). Вы получите легкий HTML для более медленных браузеров / компьютеров. Мне нравится PrimeFaces - это просто и хорошо задокументировано. Второе место - IceFaces
  • Если вы создаете веб-сайт (НЕ веб-приложение), где вам нужно воплотить жизнь в HTML (вместо создания корпоративного приложения, которое вписывается в браузер), используйте Wicket (если вы предпочитаете компонентный подход, тянуть отношение) или SpringMVC (если вы предпочитаете шаблон на основе , толкайте настрой) или просто используйте Play! фреймворк. Помните, что создание богатых компонентов на основе данных будет намного сложнее, но вы будете контролировать каждый тег html (вашему дизайнеру HTML / графики это понравится)
Петр Гвязда
источник
21
Я не понимаю, как ваш собственный ответ соотносится с вопросом ...
Пере Виллега
1
-1 Кажется очень неуместным принимать этот ответ, поскольку в нем даже не упоминается Java EE 6. Более того, он не затрагивает ни один из вопросов, поднятых в хорошо продуманном (и гораздо более высоко оцененном) @Pascal Thievent ответ.
user359996
1
Собственно вопрос не более актуален. JEE 6 сейчас очень зрелый, вопрос был задан не в марте 2010 года.
Петр Гвязда,
@PiotrGwiazda Каким образом JEE 6 изменился с тех пор? Тогда люди боялись этого больше, но это был в основном тот же самый JEE 6.
ymajoros
1
Я имел в виду, что реализации JEE6 более зрелые и доступные. JBoss 7 теперь стабилен, и доступно больше реализаций. Сообщество теперь тоже больше. Больше инструментов и библиотек теперь поддерживают стек JEE 6.
Петр Гвязда,
8

Прочтите книгу Адама Бьена « Будущее предприятия Java ... Ясно» (Java EE с / без Spring и наоборот) , включая комментарии, чтобы понять обе стороны медали. Я выберу Spring по нескольким причинам, и следующая - одна из них (воспроизведение одного из комментариев к публикации)

«Я не уверен, о каком сервере Java EE 6 вы говорите. Имеется сертификат Glassfish и TMAX JEUS. Пройдет некоторое время (читай: годы), пока совместимые с Java EE 6 версии WebSphere, WebLogic, JBoss и т. Д. Не появятся в производстве и не будут использоваться в реальных приложениях. Spring 3 просто требует Java 1.5 и J2EE 1.4, поэтому его можно легко использовать практически во всех средах '

Адишеша
источник
6
Ровно ровно год спустя, и JBoss AS 6, поддерживающий Java EE 6, в настоящее время используется в производстве.
Arjan Tijms,
8

Мое мнение основано на том, что не упоминается другими, а именно на том, что код в моей работе, как правило, живет десятилетиями (буквально), и, следовательно, поддержка очень важна для нас. Сопровождение собственного кода и используемых нами библиотек. Наш собственный код мы контролируем, но в наших интересах, чтобы библиотеки, которые мы используем, поддерживались другими в течение вышеупомянутых десятилетий или дольше.

Короче говоря, я пришел к выводу, что лучший способ добиться этого - использовать реализации спецификаций Sun с открытым исходным кодом вплоть до необработанной JVM.

Из реализаций с открытым исходным кодом Apache Jakarta доказала, что поддерживает свои библиотеки, и недавно Sun проделала большую работу по созданию высококачественных реализаций для Glassfish v3. В любом случае у нас также есть исходный код для всех модулей, поэтому, если ничего не помогает, мы можем поддерживать их сами.

Спецификации Sun обычно очень строгие, что означает, что реализации, соответствующие спецификации, могут быть легко заменены. Просто взгляните на контейнеры сервлетов.

В этом конкретном случае я бы посоветовал взглянуть на JavaServer Faces просто потому, что он является частью Java EE 6, что означает, что он будет доступен и поддерживаться в течение очень, очень долгого времени. Затем мы решили дополнить MyFaces Tomahawk, поскольку он дает некоторые полезные дополнения, и это проект Джакарты.

Нет ничего плохого в JBoss Seam или других. Просто они меньше внимания уделяют вопросам технического обслуживания, которые так важны для нас.

Торбьёрн Равн Андерсен
источник
Оказалось, что Java ServerFaces 2 в Java EE 6 может делать то, что нам нужно для Tomahawk с JSF 1. Это вполне функциональная структура (но немного тяжелая для XML)
Торбьорн Равн Андерсен
Замечательный момент, к сожалению, люди часто забывают, что программное обеспечение создано, чтобы жить десятилетиями, и что долгосрочная поддержка является ключевым моментом.
Timmz
6

Я вижу, как использовать Spring, если он у вас уже есть, но в чем смысл нового проекта? Я бы пошел напрямую с Java EE 6 (ejb3, jsf2.0 и т. Д.)

Если клиента устраивает Flex, дерзайте. Используйте BlazeDS или аналогичный - без mvc. Вы можете потратить больше времени на эту часть (обмен данными между сервером и клиентом), но у вас есть полный контроль с обеих сторон.

Не используйте Vaadin, если вы не хотите убить свой браузер. Кроме того, вы тратите больше времени на обход кода, когда ваши страницы становятся более сложными. Кроме того, необходимо полностью изменить ваше мышление, и все, что вы знаете о разработке стандартного интерфейса, будет напрасно. Аргумент, что вам не нужно использовать HTML или JS, не имеет особого смысла. Вы все равно должны это знать, даже если вы им не пользуетесь. В конечном итоге он отображается в HTML и JS. Затем попробуйте отладить его - убедитесь, что у вас есть несколько дней для простых вещей. Кроме того, я не могу представить себе веб-разработчика, который не знает html / js.

Я просто не понимаю, почему люди пробуют все эти абстракции вместо того, чтобы напрямую использовать Java EE.

Марцин Козиарски
источник
5

Почему до сих пор ходят слухи о том, что EJB станет тяжеловесом в 2010 году? Кажется, люди не обновляются в технологиях Java EE. Просто попробуйте, вы будете приятно удивлены, насколько все упрощается в Java EE 6.

Нэш
источник
4

Ответ на ваши вопросы зависит от требований вашего проекта. Если вам не требуются функции Java EE, такие как очереди сообщений, глобальные транзакции, управляемые контейнером, и т. Д., Тогда используйте tomcat + spring.

Также по опыту я обнаружил, что проекты, требующие большой интеграции веб-сервисов, планирования и очередей сообщений, лучше всего выполнять с использованием некоторого стека Java EE. Хорошо, что с помощью Spring вы все еще можете интегрироваться с модулями Java EE, работающими на сервере приложений.

Java EE 6 сильно отличается от предыдущих выпусков и действительно все упрощает. Java EE 6 сочетает в себе лучшие идеи разнообразного сообщества Java - например, Род Джонсон из среды Spring принимал активное участие в создании JSR внедрения зависимостей в Java EE 6. Преимущество использования Java EE 6 заключается в том, что вы кодируете в соответствии с стандарт, который может быть важен в некоторых организациях для поддержки поставщиков и т. д.

GlassFish v3 поддерживает Java EE 6, он довольно легкий и запускается очень быстро. Для своих разработок я использовал Glassfish v3, и его действительно легко настроить. Он поставляется с очень удобной консолью администратора, которая позволяет графически администрировать сервер.

Если вы используете GlassfishV3 и JSF 2, вы можете воспользоваться преимуществами функций CDI Java EE 6, которые позволяют легко создавать диалоги (например, страницы, подобные мастеру) в JSF.

При этом использование Java EE 6 также требует от вас изучения нового API. В зависимости от доступных временных рамок это может быть не лучшим выбором для вас. Tomcat существует уже много лет, и комбинация tomcat + spring была принята во многих веб-проектах, что означает, что вокруг много документации / форумов.

Раз
источник
Я не согласен с вашим первым предложением, выбор не в том, использовать JMS или нет. И я не думаю, что JSR-330 так важен в Java EE 6 (он больше там по политическим причинам), важная часть - JSR-299 (CDI). По крайней мере, это мое мнение.
Паскаль Тивент,
Согласитесь, что была некоторая политика, связанная с JSR330 - тем не менее, это очень важно, поскольку оно обеспечивает общую основу для внедрения зависимостей в Java (SE или EE), а не делает DI технологией только для JEE. Кроме того, он поддерживается фреймворком Spring и Google Guice, что означает, что он упростит перенос кода Spring / Guice на JEE6 или наоборот. JSR299 также был разработан для расширения возможностей JSR330. Вы правы в том, что для веб-приложений в JEE6 JSR299 абсолютно необходим. Благодаря этим двум JSR, JEE6 и Spring имеют очень похожую модель программирования. Спасибо за ваш комментарий!
Raz
3

Я работал как с Spring, так и с Java EE 6. По своему опыту могу сказать, что если вы выбираете старый JSP или проприетарный Flex, то вы в безопасности, если останетесь со Spring.

Но если вы хотите продвинуться вперед с JSF, то пора перейти на Java EE 6. С Java EE 6 вы переходите к Facelets и стандартизированным библиотекам сценариев и библиотекам компонентов. Больше никаких несовместимостей скриптов и матриц библиотек компонентов.

Что касается Spring MVC, это хорошо, если ваш проект не становится слишком большим. Если это огромное корпоративное приложение, придерживайтесь Java EE 6. Потому что это единственный способ упорядоченного обслуживания собственных библиотек компонентов и пакетов ресурсов.

user373480
источник
1
Спасибо за ваш комментарий. Мой выбор был Spring + Vaadin.
Петр Гвязда
3

Если вам нужен полный стек Java EE, я рекомендую GlassFish 3.1. Он запускается очень быстро по сравнению с другими контейнерами Java EE, которые частично или полностью реализуют Java EE 6 (JBoss 6, WebLogic 10.3.4), повторное развертывание занимает секунды, и почти все может быть выполнено по соглашению, а не по настройке, это очень удобно.

Если вам нужно что-то «легкое», вы можете настроить Apache Tomcat 7.x с желаемыми функциями. Я много использовал следующие библиотеки: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - только локальные транзакции ресурсов JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Я был разработчиком Java EE в течение последних 10 лет (я страдаю от ранних EJB, JSF и веб-технологий), Java EE 6 очень прост, хорошо связан, а текущее оборудование работает без сбоев, поэтому первоначальные причины, по которым мотивированный Spring, больше не актуальны.

ссамайоа
источник
1
Мне нравится твой ответ. Очень разумно. Когда я разместил вопрос, JEE6 был очень молод, а Tomcat 7 еще не закончен. «Первоначальные причины, которые мотивировали Spring, больше не актуальны» - это правда, но JEE6 с CDI нужно время, чтобы исправить это. Например: мониторинг Javamelody доступен для Spring и Guice (я не могу представить, как работать с приложениями без него). EHcache доступен для Spring (я имею в виду результаты методов кеширования). Многие вещи, такие как программирование аспектов, все еще проще в Spring, потому что множество сторонних библиотек и фреймворков легко интегрируются со Spring, но еще не с JEE6.
Петр Гвязда
1

Я по-прежнему предпочитаю весну.

И я бы перешел на JSF. Я думаю, это мертвая технология. Spring MVC будет лучшей альтернативой. Как и Flex. Подумайте о первых контрактах на услуги XML, и вы сможете полностью отделить серверную часть от пользовательского интерфейса.

Duffymo
источник
1
Я создал несколько приложений с использованием Java + Flex и PHP + Flex, и я согласен, что это лучшее решение для богатых интерфейсов. Но в этом приложении я не могу использовать Flex :( Мне нужен какой-то высокоуровневый интерфейс, поэтому Spring MVC не является решением. Я хочу подумать о сортируемых данных, кроме <tr> <td> в цикле.
Петр Gwiazda
1
@duffymo - Я могу поспорить, хороший ли выбор flex. JSF определенно не мертв, особенно с такими библиотеками, как richfaces, primefaces, icefaces и т.д.
Bozho
1
В IceFaces я создаю меню, деревья, датагриды используют действия, события, и я не думаю, что страница перезагружается или это запрос ajax. Сортированный datagrid или загруженное дерево ajax - это встроенный компонент. В Spring MVC я работаю с HTML-таблицами, списками и т. Д. Мне нужно использовать стороннюю инфраструктуру javascript и вручную создавать магию AJAX. Я бы хотел сделать это во Flex, но это политическое / деловое решение, а не мое.
Петр Гвязда
1
Мои текущие два проекта JSF определенно не умерли;) И я гораздо больше удовлетворен способом JSF для создания RIA (для этого «богатый» на «richfaces»), чем использованием Flex. Один даже станет публичным на следующей неделе.
Bozho
2
Я действительно хотел бы знать, почему вы все еще предпочитаете Spring, Java EE 6 чертовски хорош. Вам не кажется, что работа на открытой платформе важна для будущего Java?
Паскаль Тивент,
0

Я бы порекомендовал Spring + Tomcat, если только вы не можете дождаться, пока Glassfish v3 и Weld станут более зрелыми. В настоящее время существует несколько проблем с потреблением памяти / загрузкой процессора при запуске Glassfish с приложениями с поддержкой CDI.


источник
0

Не читал все, но просто чтобы сказать, что теперь вы можете использовать EJB3 в войне против Java EE 6, чтобы вы могли использовать EJB3 на Tomcat (я думаю).

Себастьян Лорбер
источник
Да, вы можете упаковать EJB в WAR в Java EE 6, но это не значит, что вы можете развернуть такую ​​WAR на Tomcat. Вам нужен контейнер, реализующий веб-профиль, а Tomcat - нет, и на самом деле в сообществе Tomcat нет плана по его реализации (см. Old.nabble.com/Java-EE-6-Web-Profile-td27715793.html ). Но есть веб-профиль GlassFish v3, будет Resin ...
Паскаль Тивент,
2
обновление: взгляните на проект TomEE
gpilotino
-3

Я рекомендовал вам Tomcat со Spring, потому что:

  1. Spring может создавать вспомогательные компоненты для JSP
  2. Вы будете использовать Spring для сохранения объекта через JPA

Это хороший выбор, потому что вам не нужна тяжелая обработка.

бассем
источник
1
«Тяжеловесная переработка»? Не могли бы вы уточнить? Мне любопытно.
Паскаль Тивент