Ladislav Thon created WFLY-11373: ------------------------------------ Summary: EE naming context not set when @Initialized(ApplicationScoped.class) event is fired in some cases Key: WFLY-11373 URL: https://issues.jboss.org/browse/WFLY-11373 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 14.0.1.Final Reporter: Ladislav Thon Assignee: Matej Novotny Since [this commit|https://github.com/wildfly/wildfly/commit/3659f4738aa3b08515b93ca3...] (which fixed WFLY-9732), the EE naming context is not set up properly when {{WeldBootstrap.endInitialization()}} is called. This is because the naming context is set up by the {{SetupAction}} executed in {{WeldStartService}}. ({{WeldBootstrap.endInitialization()}} used to be invoked from {{WeldStartService}} as well, but the commit linked above moved the invocation to a separate {{WeldStartCompletionService}}.) That is a problem because {{endInitialization()}} is where the {{(a)Initialized(ApplicationScoped.class)}} event is fired from (in some cases). If there's a bean that's being eagerly-initialized by listening for this event and the bean also requires the EE naming context (e.g. for injecting {{@Resource(lookup = "java:comp/DefaultManagedThreadFactory")}}), deployment now fails (because the resource injection fails). I can see this problem in Thorntail, because the pattern described above is used by SmallRye FaultTolerance (see [HystrixInitializer|https://github.com/smallrye/smallrye-fault-tolerance/b...] and [DefaultHystrixConcurrencyStrategy|https://github.com/smallrye/smallrye-fa...]). -- This message was sent by Atlassian Jira (v7.12.1#712002)