Каковы, вероятно, будут самые большие изменения (потери) перехода от Seam 2 к простой JavaEE 6?
Вопрос в значительной степени говорит сам за себя, хотя в явном виде я ищу то, что мне, вероятно, будет не хватать в Seam 2 в среде Java EE 6 ("потери").
Для моего последнего (небольшого) проекта JavaEE 6 или, более конкретно, JSF 2 было требованием исправления, поэтому использование Seam 2 не было вариантом (и не будет). Хотя некоторые люди говорили, что Seam 2 работает с JSF 2, я так и не сделал этого. До сих пор я использовал только Seam 2, и я боюсь, что переключение на простую среду JavaEE представляет большую проблему, чем я знаю в настоящее время.
Проект имеет следующие основные / основные требования:
- Ролевая и основанная на разрешениях концепция безопасности (~50 пользователей)
- JPA 2 транзакционная стойкость
- ...
Остальные будут скорее основаны на графическом интерфейсе пользователя, формах поиска, проверке клиента и т. Д., Которые будут обрабатываться проверкой компонентов RichFaces 4 и JavaEE 6. Здесь нет веб-сервисов, нет релакс-URL, нет сообщений, нет электронной почты.
Я вижу, что использование безопасности Seam определенно будет потерей, но я не уверен в том, какой будет устойчивость Seam, структура сущностей / запросов, JBoss EL и другие, особенно общая модель программирования (навигация, EL, компоненты), Обратите внимание, что мы сможем добавить модули Seam 3, когда это будет целесообразно, поэтому вы можете включить Seam 3 в обсуждение в разделе "выгоды".
Итак, кто-нибудь может немного прояснить это? (это не должно быть полным завершением, что бы ни пришло в голову, продолжайте)
PS: мне не удалось подключиться к форумам Seam, поэтому я решил спросить здесь.
2 ответа
Хороший и понятный вопрос - я не понимаю, почему за него проголосовали.
Что я могу вам сказать - на фоне различных приложений Java EE 5 / Seam 2 и Java EE 6 / Seam 3:
Нет ничего, что вы не могли бы решить с помощью Java EE 6 / Seam 3, и многие вещи кажутся более зрелыми (например, типизированный безопасный CDI намного лучше, чем строковые компоненты Seam 2, JBoss AS 7 намного лучше, чем все другие выпуски).
Но: хотя Seam 2 больше похож на универсальное решение для всех требований, с которыми вы можете столкнуться в корпоративном веб-приложении, с Java EE 6 вы почти наверняка столкнетесь с большим количеством загадок из разных модулей.
Шов 3 является отличным началом, но он не совсем готов к производству, по крайней мере, не во всех частях. Таким образом, вам придется иметь дело с проблемами и исключениями, которые еще предстоит решить. Это, безусловно, разница с Seam 2.x, где дорога выглядела довольно хорошо вымощенной.
Не существует эквивалента интегрированной концепции навигации / потока страниц в Seam 2. Вы должны либо использовать навигацию JSF 2, либо интегрировать Drools или что-то вроде этого - самостоятельно.
Вложенные разговоры - это то, что вам может понравиться в Seam 2. В CDI такого нет, но OpenWebBeans / CODI предлагает хорошее решение в качестве расширения CDI.
Весь материал с графическим интерфейсом (pdf, рассылка, отчётность) находится в стадии разработки в Seam 3, но пока не готов на 100% (9/2011). Это изменится в следующий раз - но сейчас вы уже на пути к альфа и бета-версиям.
Сказав это, вот мой совет:
Переключитесь на Java EE 6 / CDI как можно скорее (и спорно). Это так много будущего.:-)
Я испытал то же самое. Java EE недостаточно в нескольких случаях, и это не было задумано. Итак, есть расширения CDI. Несколько дней назад я узнал, что другие испытали то же самое:
Если это слишком легко, чтобы быть правдой
Если вы являетесь пользователем Seam2, переходите на Seam3 (я думаю, что они планируют предоставить аналогичные материалы снова - просто разговоры очень плохие) и помогите им добиться стабильности, добавить функции, которые вы пропустили,... или переключиться на другие расширения. Есть много, например, мы предпочитаем MyFaces CODI, потому что он очень стабилен и быстр, и их представление о разговорах лучше. Существует также очень открытое сообщество, и они также очень помогают, слушают идеи,...
Вопрос не в том, "что", а в том, "когда это будет доступно в расширении". Я думаю, как только кто-то попросит функцию.