JSF – 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!
Reference: JSF – Eager CDI beans from our JCG partner Oleg Varaksin at the Thoughts on software development blog.
In NetBeans 7.3, your code:
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({TYPE})
public @interface Eager
{
}
Causes the following 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’}.
Anybody got a fix or a work-around?
Thanks, Bill
Hi this was a very informative article. I’ve never dealt with extensions before. I”m just now becoming familar with CDI. I followed these instructions exactly — I’m building a Map to be used as a select list in a search page and I want it initialized while the app is being deployed. I’d previously implemented it as an eager=true @ManagedBean before I switched from JSF2 to CDI.
I’m getting this error now during deployment
WELD-001408 Unsatisfied dependencies for type [StateList] with qualifiers [@default] at injection point [[field] @Inject gov.ssa.dne.nmst.view.Search.stateList]
I can’t understand which unsatisfied dependencies it’s refering to.
I followed the code to the letter but the Collect method is not scanning my classes. It does scan something like 53 classes in org.jboss.weld.bean and in com.sun.jersey.server.impl.cdi. I tried everything I could think of to no avail. I’m stuck… Any suggestions?