Пользовательская реализация jsf с пользовательской структурой di

Как и JSF 2.3, @ManagedBean и другие аннотации javax.faces.bean. * Устарели и заменены JavaEE 6 CDI.

Я успешно создал образец проекта JSF и развернул его в WebLogic с использованием серверных реализаций glassfish.jsf.jar и без реализации JSF или CDI в WEB-INF / lib.

Но я боюсь застрять в реализации сервера, который иногда может быть устаревшим + мое приложение ведет себя по-разному во время работы на разных серверах приложений, поэтому я думаю, что было бы лучше, если бы я контролировал реализацию JSF.

Я потратил последние 4 дня на поиск способа использования пользовательской реализации JSF (Mojarra или MyFaces) с использованием новых аннотаций CDI или любой другой структуры DI, но безуспешно.

Я понял, что должен использовать серверную реализацию JSF и CDI на JavaEE, если хочу избавиться от @ManagedAnnotations.

Мой вопрос: есть ли способ включить мою предпочтительную реализацию JSF и CDI в мою WAR, которая будет развернута на разных серверах приложений, таких как WebLogic и WildFly.

Примечание: я нашел старый вопрос от 2013 года с ответом "Нет", но я хочу знать, действителен ли этот ответ.

Изменить 02/11/2018: Я без проблем установил проект со встроенным JSF (Mojarra) и CDI (Weld) на Tomcat Server. Я думаю, это потому, что Tomcat - это контейнер сервлетов, поэтому конфликтов нет.

Я думаю, что моя проблема связана с конфликтом между моим встроенным CDI и серверной версией Weld. Я не могу найти решение, чтобы мое приложение было черным ящиком.

Я использовал этот weblogic.xml ложный

    <prefer-application-packages>
        <package-name>!javax.servlet.*</package-name>   
    </prefer-application-packages>

    <prefer-application-resources>
        <resource-name>!javax.servlet.*</resource-name>
    </prefer-application-resources>

Я знаю, что WildFly позволяет на лету менять реализации JSF. Это может частично решить вашу проблему. Однако оба сервера заблокированы в реализациях CDI (на самом деле он должен быть сварен в обоих), потому что для внутренней обработки поддержки EJB, перехватчиков, подключения к жизненным циклам сервера и т. д. Я не могу себе представить, чтобы сервер легко заменил CDI реализация если честно. (почти) Все технологии EE каким-либо образом интегрируются с CDI, и в лучшем случае вам понадобится API / SPI конкретного поставщика для сервера, чтобы справиться с этим.

Siliarus 05.11.2018 13:59

@Siliarus Я тоже «не могу представить, чтобы сервер легко заменил реализацию CDI», но я попросил убедиться, прежде чем принимать решение. Я не могу понять преимущества такого скрепления между CDI и JSF, поскольку это затрудняет обновление, если текущая реализация сервера имеет проблемы. Weblogic не предоставляет версию с года.

Karim Ahmed 06.11.2018 07:32

Я бы сказал, просто используйте WildFly, он обычно довольно актуален и его легко обновить до новых версий.

Siliarus 06.11.2018 08:51

@Siliarus Проблема в том, что у нас два клиента. один из них использует WebLogic без намерения вносить изменения, поэтому приложение будет работать на разных реализациях и / или версиях JSF и CDI. Я думаю, что будет предпочтительнее использовать JSF2.2 и Spring, чтобы избежать каких-либо проблем в будущем. Как вы думаете?

Karim Ahmed 06.11.2018 09:52

Я не знаком со Spring, чтобы судить об этом. Хотя действительно ли вашим клиентам нужны самые свежие версии реализации? В конце концов, технические характеристики меняются не так часто ...

Siliarus 07.11.2018 13:00
0
5
136
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Другой ответ вроде все еще актуален. Но есть и другие (лучшие) варианты

1 Также предоставьте полный контейнер java-ee как часть вашего приложения.

2 Требовать минимальную версию определенных серверов приложений

3 Сообщите клиентам, что им нужны хотя бы определенные версии определенных библиотек.

Спасибо. Я считаю, что ваш ответ правильный, но я подожду еще пару дней. Для варианта 1: я не знаю, как это сделать, не могли бы вы дать мне ссылку на пример. Варианты 2 и 3: Моя проблема, если я столкнусь с ошибкой в ​​текущей нашей версии реализации Weblogic12c 12.2.1.0 на нашем сайте клиента или в последней версии 12.2.1.3, тогда нам придется использовать обходные пути, если они доступны, или принять недостаток. Кроме того, обновление - это непростая задача, поскольку у нашего клиента много старых приложений, развернутых рядом с нашим. Поэтому я думаю, что буду использовать JSF 2.2 со Spring, пока не найду решение.

Karim Ahmed 06.11.2018 07:18

В чем преимущество использования Spring? MyFaces 2.3 по-прежнему работает без CDI, не знаю, работает ли Mojarra 2.3 без CDI. Однако в JSF 3.x CDI будет обязательной зависимостью. Если вам необходимо поддерживать множество версий серверов приложений JavaEE и JavaEE, было бы лучше всего основать ваше приложение на JSF 2.0 и CDI 1.0. Это поддерживается начиная с JavaEE6 и, вероятно, будет работать даже с JavaEE9, если вы не используете @ManagedBeans ....

tandraschko 12.11.2018 19:20

Mojarra 2.3 все еще работает без CDI, но с предупреждением о том, что @ManagedBean устарел. Я намеревался использовать Spring в качестве замены CDI, но я считаю, что теперь, если мы собираемся использовать JSF, мы должны рассмотреть возможность использования полного стека JEE для совместимости с будущими обновлениями проекта или использовать встроенный JSF 2.2 без намерения обновлять его с помощью Spring.

Karim Ahmed 26.11.2018 08:11

Другие вопросы по теме