Monday, February 18, 2013

Eager CDI beans

Everybody knows eager managed beans in JSF 2. @ManagedBean has an eager attribute. If eager="true" and the scope is application, then this bean must be created when the application starts and not during the first reference to the bean. This is a nice feature when you want to load application scoped data (e.g. some select items for menus) during application startup in order to increase the performance at runtime.
@ManagedBean(eager=true)
@ApplicationScoped
public class GlobalBean {
    ...
}
@ManagedBean annotation will be deprecated with JSF 2.2. It is highly recommended to use CDI (context dependency injection) beans in JEE environment. But what is the equivalent to the eager managed beans in CDI? Well, CDI is flexible, you can write portable CDI extensions. I asked Thomas Andraschko how to do this. Thomas is a CDI expert, co-owner of PrimeFaces Extensions and the committer in OpenWebBeans (OWB) project. His tip was to implement such extension as follows
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({TYPE})
public @interface Eager
{
}
package mydomain.mypackage;

import java.util.ArrayList;
import java.util.List;
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.AfterDeploymentValidation;
import javax.enterprise.inject.spi.Bean;
import javax.enterprise.inject.spi.BeanManager;
import javax.enterprise.inject.spi.Extension;
import javax.enterprise.inject.spi.ProcessBean;

public class EagerExtension implements Extension {
    private List<Bean<?>> eagerBeansList = new ArrayList<Bean<?>>();

    public <T> void collect(@Observes ProcessBean<T> event) {
        if (event.getAnnotated().isAnnotationPresent(Eager.class)
            && event.getAnnotated().isAnnotationPresent(ApplicationScoped.class)) {
            eagerBeansList.add(event.getBean());
        }
    }

    public void load(@Observes AfterDeploymentValidation event, BeanManager beanManager) {
        for (Bean<?> bean : eagerBeansList) {
            // note: toString() is important to instantiate the bean
            beanManager.getReference(bean, bean.getBeanClass(), beanManager.createCreationalContext(bean)).toString();
        }
    }
}
The extensions should be registered in a file META-INF/services/javax.enterprise.inject.spi.Extension. The file has only one line with a fully qualified path to the EagerExtension class, e.g. mydomain.mypackage.EagerExtension.

Using is simple. Assume, we have an application scoped LayoutController CDI bean which is responsible for the entire layout configration. We can annotate it with @Eager and speed up the layout creation.
@ApplicationScoped
@Eager
@Named
public class LayoutController implements Serializable {
    private LayoutOptions layoutOptions;

    @PostConstruct
    protected void initialize() {
        layoutOptions = new LayoutOptions();

        LayoutOptions panes = new LayoutOptions();
        panes.addOption("slidable", false);
        panes.addOption("spacing", 6);
        layoutOptions.setPanesOptions(panes);

        ...
    }

    public LayoutOptions getLayoutOptions() {
        return layoutOptions;
    }
}
Have fun with CDI!

14 comments:

  1. Hi Oleg,

    just to understand: what's the advantage over a Singleton Session Bean with the @Startup annotation? Since you're using JEE anyway...

    ReplyDelete
  2. As front-end developer I don't use EJBs. This is another layer.

    ReplyDelete
  3. Very good just the thing I was looking for a couple of months ago.

    ReplyDelete
  4. I have been looking this type of information for a while because I am also working in Software Development Company Malaysia. I'd like to say thanks and want to say cheer!

    ReplyDelete
  5. Your post is very informative, I appreciate you for producing this great article, I want to say thanks to you for this awesome post..

    ReplyDelete
  6. Oleg, in NetBeans 7.3, your code:

    @Target({TYPE})

    causes this error:

    The CDI Annotation is declared as Qualifier but it has wrong target values. Correct target values are '{METHOD, FIELD, PARAMETER, TYPE'} or '{FIELD, PARAMETER'}.

    Do you have a fix or work-around?

    Thanks, Bill

    ReplyDelete
  7. Just remove the @Qualifier from @Eager, this is not required.

    ReplyDelete
  8. Nice one Oleg! :)

    Singleton beans ARE indeed an alternative, and they theoretically can be used in the front-end as pure front-end beans. They are part of the web profile and can be put in a .war.

    Historically EJBs were for back-end business logic only, but these days (again theoretically) they are just beans and a developer can decide for what purpose to use them.

    That said, practically speaking I see that many projects have the distinction EJB = business, CDI/JSF Managed beans = web/front-end. One must also take care that a Singleton comes with some baggage by default that might not be needed; every method acquires a lock AND starts a transaction. For many use cases in a web environment you would need to disable those. This makes an eagerly loaded CDI bean such as presented here a more natural solution.

    P.s.

    Regarding the deprecation; JSF managed beans are still not officially deprecated, not even in JSF 2.2. You could say though that they are effectively deprecated as of JSF 2.2.

    I hope JSF 2.3 will officially deprecate them and maybe start the Java EE pruning process even.

    ReplyDelete
  9. I just encountered a small issue with the extension and that is that it gives the following error when a producer method is used.

    For instance:

    org.jboss.weld.exceptions.IllegalArgumentException: WELD-001305 The given type class org.wamblee.photos.model.plumbing.Producer is not a type of the bean Producer Method [Configuration] with qualifiers [@Eager @Any] declared as [[BackedAnnotatedMethod] @Produces @Eager @ApplicationScoped public org.wamblee.photos.model.plumbing.Producer.getConfiguration()]


    In this case I defined a Producer class that has a producer method

    @Produces
    @Eager
    @ApplicationScoped
    public Configuration getConfiguration() {...}

    The problem is that bean.getBeanClass() returns the class that contains the producer method (i.e. Producer) instead of configuration.

    I could solve this problem by using the following code instead to create the bean:

    CreationalContext ctx = beanManager.createCreationalContext(bean);
    bean.create(ctx).toString();

    Nevertheless, I now see the bean being constructed twice. Once when I deploy the application (war) and once when it is injected for the first time into an object. Probably I am still not using the CDI API correctly. This happens both when I use the eager extension for a producer method or for a simple bean that is annotated with @Eager.

    ReplyDelete
  10. Really good stuff here, Oleg and Thomas, and all that commented/responded! I didn't know about this blog until scouring OmniFaces issue list.

    OmniFaces issue 286: Add CDI compatible @Eager
    https://code.google.com/p/omnifaces/issues/detail?id=286

    ReplyDelete
  11. Great stuff thanks, it helped me a lot :-)

    ReplyDelete
  12. It annoys me this kind of very useful feature is not out-of-the-box. What the hell? Are CDI creators idiots or what?

    ReplyDelete
  13. With @Observes the bean is created at startup too, also without Eager?

    ReplyDelete
  14. public class MainClass {

    public static void main(final String... args) throws Exception {
    StartMain.main(args);
    }

    public final void start(@Observes final ContainerInitialized event) throws Exception {
    System.out.println("Start...");
    }

    }

    public class AutoStart {

    public void start(@Observes final ContainerInitialized event) {
    System.out.println("Hey I started.");
    }
    }

    This should print
    Start...
    Hey I started.

    Thanks to Alessandro Mattiuzzi

    ReplyDelete

Note: Only a member of this blog may post a comment.