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