[cdi-dev] [JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean

[Mark Struberg (JIRA)]

    [ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181733#comment-13181733 ] 

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...


> Standardize eager initialisation of ApplicationScoped bean
> ----------------------------------------------------------
>
>                 Key: CDI-473
>                 URL: https://issues.jboss.org/browse/CDI-473
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>            Reporter: Antonin Stefanutti
>             Fix For: 2.0 (discussion)
>
>
> Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called.
> While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.:
> {code}
> void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) {
>     for (AnnotatedType<?> type : eagerBeans)
>         // Calling toString is necessary to force the initialization of normal-scoped beans
>         BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString();
> }
> {code}
> There should be a concise way to declare that intent which would then be address by the CDI container, for example:
> {code}
> @ApplicationScoped(eager = true}
> class EagerApplicationScopedBean {
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)