[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-473: ----------------------------------- TL;DR: imo we don't need any @Startup here for the long explanation: *) As Jozef already explained there is @Observers @Initialized(ApplicationScoped.class). *) [~meetoblivion] good point, but one could check that in the code easily. (if bla==null..) *) the @Startup + @Postconstruct has one HUGE downside: As JSR-250 defines a bean must only be made available _after_ PostConstruct did finish. That means that no other bean we call us before the init is finished. That causes tons of problems, e.g. defeats circular injection (which proxies usually solve), the boot order etc. THAT was the reason why EJB had to introduce the whole depends-on stuff in the first place. And it is really ugly and hard to get right. With the eventing solution it's pretty smooth. The only 'problem' currently in this area that the @Initialized and @Destroyed events for ApplicationScoped does NOT reflect the real lifecycle of the ApplicationContext. [1] [1] for those who like to dig deeper: All CDI Extensions are defined to be available as @ApplicationScoped beans. Thus the ApplicationContext hast to be available right after the CDI extensions get loaded, means way before we even fire the first @BeforeBeanDiscovery event. And the ApplicationContext must also exist until the last CDI Extension got the @BeforeShutdown event. In OWB we first fire the @Destroyed(ApplicationContext.class) then destroy the 'user' beans and only then fire all the BeforeShutdown. And only after that we really destroy the ApplicationContext. Not sure if Weld does something similar, but that's what worked best so far... -- This message was sent by Atlassian JIRA (v6.4.11#64026)