Инъекция CDI в JSP - PullRequest
Новая
       36

Инъекция CDI в JSP

5 голосов
/ 12 сентября 2011

В JSP можно использовать управляемые компоненты CDI, используя выражения EL, такие как $ {myBean.myAttribute}. Здесь нет проблем.

Я хотел бы использовать «обычное внедрение» (т.е. без использования выражений EL) с @Inject в файлах JSP, например: <%! @ Inject MyBean myBean; %> затем позже <% = myBean.getMyAttribute ()%>. Даже если этот пример может быть достигнут с помощью выражений EL, некоторые другие варианты использования не могут.

Похоже, это не полностью поддерживается серверами приложений:
- JBoss 6.0.0, JBoss 6.1.0, Resin 4.0.22: все в порядке.
- JBoss 7.0.1, GlassFish 3.x (было протестировано несколько версий): СБОЙ, myBean остается нулевым.

В JSP должно работать нормально, так как:
(1) он отлично работает в сервлетах в соответствии с различными спецификациями и
(2) JSP переводится в сервлет во время выполнения.

Ребята, вы знаете, поддерживается или нет то, что я пытаюсь сделать? Может быть, есть какая-то внутренняя информация о реализации?

Ответы [ 3 ]

2 голосов
/ 12 сентября 2011

Интересный вопрос, если бы вы не тестировали его, я бы поставил немного денег на тот факт, что он не работает; -)

CDI основан на управляемых бинах (JSR 316).Соответствующее определение довольно умышленно (специально):

Из спецификации:

Управляемый компонент может быть объявлен путем аннотирования его класса аннотацией javax.annotation.ManagedBean.Управляемый компонент не должен быть: конечным классом, абстрактным классом, нестатическим внутренним классом.Управляемый компонент может быть не сериализуемым, в отличие от обычного компонента JavaBean.

В базовой модели компонентов Управляемые компоненты должны предоставлять конструктор без аргументов, но спецификацию, основанную на управляемых компонентах, например, CDI (JSR).-299), может ослабить это требование и позволить управляемым компонентам предоставлять конструкторам более сложные сигнатуры,

Вероятно, происходит то, что контейнер сканирует путь к классам и обнаруживает скомпилированные сервлеты JSP.Прошло много времени с тех пор, как я последний раз видел его, но я помню, что код сгенерирован и все (включая скриптлеты) попадает в doGet() или doPost() ...!?Так что, хотя они формально не дисквалифицируют в терминах определения, я сомневаюсь, что сценарий JSP - это то, что вы хотите считать управляемым компонентом.Честно говоря, это звучит ужасно неправильно; -)

Я уже довольно давно слежу за списками рассылки CDI / Weld / Seam, и не помню, чтобы JSP когда-либо упоминался.То же самое с поиском в Google этого соединения.

Как следствие, вам не следует полагаться на CDI, работающий со скриплетами.ИМХО, такое поведение имеет больше побочных эффектов, чем интенциональных, и может быть отброшено в будущих выпусках без уведомления (или даже без замечаний :-)

Итак, +1 за предложениеJB Nizet: Используйте сервлеты с CDI, но не JSP.

ОБНОВЛЕНИЕ : Я пытался помочь, а не создавать путаницу ;-) Моя точка зрения: ИМХО это действительно очень неправильноиспользовать CDI в JSP, но я не нашел ничего в соответствующих спецификациях, которые это подтверждают.Все, что я могу сказать, это то, что JSP никогда не упоминаются где-либо - что поддерживает мои интуитивные ощущения (и соответствует наблюдению, что некоторые реализации действительно учитывают это, а другие нет).

1 голос
/ 16 сентября 2011

Я не думаю, что есть портативный @Inject, доступный из коробки для JSP, но должна быть возможность реализовать его (на уровне контейнера) так же, как он работает с сервлетами.

И хотя я согласен, что это не лучший способ использовать CDI, технически я не вижу в этом никакой причины. Например, AFAIK @Inject в сервлетах прозрачно использует прокси ThreadLocal, почему бы не использовать эту функцию в JSP?

0 голосов
/ 20 декабря 2018

Попробуйте это: - 

<%!
    @Inject
    private UserService userService;
%>

Это работает для меня:)

Примечание: Используйте скобку <%! %> вместо <% %>.

...