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