CDI and @Startup: SOLVED!

Speaking on the CDI list about CDI 2.0 standalone container API Jozef Hartinger sent an answer which is quite obvious when you know it but which can change your life if you don’t: how CDI 1.1 introduced @Startup without the need of EJBs.

@Startup or link a bean lifecycle on the container

As a quick reminder @Startup in EJB API allows to force an EJB instance to be created eagerly when the container starts. Combining it with @PostContruct you can add some application initialization logic with its deployment and combining it with @PreDestroy you get an application clean up hook:

@Startup
@Singleton
public class ProvisioningDataForApplicationLifecycle {
    @PostConstruct
    private void init() {
        // when app is deployed
    }

    @PreDestroy
    private void cleanUp() {
        // when app is undeployed
    }
}

CDI 1.0 didn’t have such an annotation and in several cases it was causing some headaches to have this feature. The most known workaround was to write a CDI Extension observing the AfterDeploymentValidation container event and retrieve the “startup” bean in this observer to call any method on it (most of the time toString() to not do anything important). Not very user friendly isn’t it? (I skip few super tricky cases where this hack was not working since we can suppose you do it with a bean you designed to work with this extension).

CDI 1.1 answer

CDI 1.1 introduces a standard way to observe lifecycle of built-in normal scopes. You just need to write an observer with the qualifier @Initialized(scopeclass) for its activation and @Destroyed(scopeclass) for its destruction. How does it solve our issue? We’d need a scope activated for the application lifetime…like application one. Using @ApplicatonScoped with these observer qualifiers allows you to use an observer to replace the EJB of the previous part. The obsever doesn’t have to be @ApplicationScoped but if you really need the EJB feature because you store anything in your bean you can scope your observer @ApplicationScoped as well.

Here is a sample:

@ApplicationScoped
public class ProvisioningDataForApplicationLifecycle {
    private final Map<String, User> users = new HashMap<>(); // + getter

    public void init(@Observes @Initialized(ApplicationScoped.class) Object init) {
        users.put("cdi", new User("cdi", "1.1"));
        users.put("deltaspike", new User("deltaspike", "1.3"));
    }

    public void destroy(@Observes @Destroyed(ApplicationScoped.class) Object init) {
        users.clear();
    }
}

Note: payload of the observer can be ServletContext for application scope as well when the application is a webapp.

What is funny with this sample is you can replace the destroy method by a standard @PreDestroy because the scope of the bean is the observed scope. You gain one annotation so it is tempting right? Issue is then if other application scoped beans rely on this particular bean then you are not sure they will be destroyed in the right order where using the observer you know ProvisioningDataForApplicationLifecycle instance will be the last one destroyed. But in real applications where this pattern is used this case is relatively rare so using the observer is just more sexy because it makes the bean symetric.

Want more content ? Keep up-to-date on my new blog

Or stay in touch on twitter @rmannibucau