Вы можете делать то, что упоминаете, и использовать @RequestScoped
bean-компоненты в сеансе @Stateless
и в компоненте @MessageDriven
.Это основная часть спецификации CDI и TCK и гарантированно переносимая.
Примечание по MDB
Имейте в виду, что существует тест для компонента @Stateless
, который использует @RequestScoped
bean, но не существует теста, который гарантирует, что bean-компонент @MessageDriven
может ссылаться на bean-компоненты @RequestScoped
.Это было просто упущением, и уже исправлено для Java EE 7 TCK .Так что просто знайте, что если это не работает для случая MDB, это может быть не вашей ошибкой:)
Обходной путь может заключаться в простом делегировании вашего MDB-компонента в SessionBean любого типа, например @Stateless
, @Stateful
и @Singleton
все имеют тесты @RequestScoped
.
Создание самого EJB в области
В то время как @Stateless
, @Singleton
и @MessageDriven
могут иметь областьссылки, введенные через @Inject
, не могут быть @RequestScoped
или другими областями.Только модель @Stateful
является достаточно гибкой для поддержки областей.Другими словами, вы можете аннотировать сам класс EJB @Stateful
как @RequestScoped
, @SessionScoped
и т. Д.
Проще говоря, @Stateless
, @Singleton
уже исправили "области видимости".@Singleton
- это, по сути, @ApplicationScoped
, а @Stateless
, возможно, будет некоторой выдуманной областью, такой как @InvocationScoped
, если таковая существует.Жизненный цикл bean-компонента @MessageDriven
полностью зависит от Connector, который управляет им, и поэтому также не может иметь определяемую пользователем область.