Q1: У меня возникают проблемы с выяснением того, где в течение этого жизненного цикла контейнера будет инициировано событие @Initialized. Я подозреваю, что это сделано AfterDeploymentValidation, но я не могу найти никакой документации, подтверждающей этот факт.
Как описано в спецификации CDI 1.1, раздел 11.5.4. Событие AfterDeploymentValidation :
Контейнер должен инициировать событие после проверки того, что проблем с развертыванием нет, и до создания контекстов или обработки запросов.
A1: Как следствие, события с квалификатором @Initialized для любой области действия будут запущены после события AfterDeploymentValidation.
Q2: Кроме того, я не могу найти ничего в спецификации CDI 1.1, которая определяет, когда и где генерируется событие @Initalized.
A2: Секция 6.7. Управление контекстом для встроенных областей описывает поведение для каждой встроенной области и предоставляет рекомендации для реализаций пользовательских областей:
Портативные расширения рекомендуется вызывать событие с квалификатором @Initialized(X.class) при инициализации пользовательского контекста.
...
Событие с квалификатором @Initialized(RequestScoped.class) вызывается при инициализации контекста запроса.
... и т.д.
Q3: Например, генерируется ли событие до или после выполнения всех методов @PostConstruct обнаруженных бинов?
Как описано в 6.7. Управление контекстом для встроенных областей :
Область запроса активна:
- ...
- во время @PostConstruct обратного вызова любого компонента.
Область применения активна:
- ...
- во время @PostConstruct обратного вызова любого компонента.
... и т.д.
A3: Чтобы область стала активной, ее нужно сначала инициализировать. Как следствие, события с квалификатором @Initialized будут вызваны до @PostConstruct обратного вызова любого компонента, но только для областей, которые должны быть активны в обратном вызове.
Q4: Событие, генерируемое до или после инициализации EJB @Startup? Есть ли документация, в которой четко указан порядок / последовательность этих событий в CDI?
A4: EJB-компоненты подпадают под отдельную спецификацию JSR 345: Базовые контракты и требования EJB Enterprise версии 3.2, .
В соответствии с разделом 4.8.1 Инициализация сессионного компонента сеанса там:
По умолчанию контейнер отвечает за принятие решения об инициализации экземпляра одноэлементного сессионного компонента. Однако поставщик компонентов может по желанию настроить одноэлементный компонент сеанса для активной инициализации. Если аннотация запуска появляется в классе одноэлементного сеансового компонента или если одноэлементный сеансовый компонент был определен с помощью дескриптора развертывания как требующий быстрой инициализации, контейнер должен инициализировать экземпляр единственного сеансового компонента во время последовательности запуска приложения. Контейнер должен инициализировать все такие одноэлементные сеансовые компоненты времени запуска перед любыми внешними клиентскими запросами (то есть
клиентские запросы, исходящие вне приложения), доставляются любым компонентам корпоративного компонента в приложении.
...
В некоторых случаях существуют явные зависимости порядка инициализации между несколькими компонентами одноэлементного сессионного компонента в приложении. Аннотация DependsOn используется для выражения этих зависимостей. Зависимость DependsOn используется в тех случаях, когда один сессионный компонент сеанса должен инициализироваться перед одним или несколькими другими сессионными компонентами сеанса. Контейнер гарантирует, что все одноэлементные сеансовые компоненты, с которыми одноэлементный сеансовый компонент имеет отношение DependsOn, были инициализированы до вызова метода PostConstruct.
Как следствие, события с квалификатором @Initialized будут запускаться до обратного вызова @PostConstruct компонента EJB, но только для областей, которые должны быть активны в обратном вызове.