A sample CDI extension for eagerly instantiating @ApplicationScoped beans annotated @startup

StartupBean.java

@ApplicationScoped
@Startup
public class StartupBean
{
    @PostConstruct
    public void onStartup()
    {
       System.out.println("Application starting up.");
    }
}

StartupBeanExtension.java

public class StartupBeanExtension implements Extension
{
   private final Set<Bean<?>> startupBeans = new LinkedHashSet<Bean<?>>();

   <X> void processBean(@Observes ProcessBean<X> event)
   {
      if (event.getAnnotated().isAnnotationPresent(Startup.class) &&
            event.getAnnotated().isAnnotationPresent(ApplicationScoped.class))
      {
         startupBeans.add(event.getBean());
      }
   }
   
   void afterDeploymentValidation(@Observes AfterDeploymentValidation event, BeanManager manager)
   {
      for (Bean<?> bean : startupBeans)
      {
         // the call to toString() is a cheat to force the bean to be initialized
         manager.getReference(bean, bean.getBeanClass(), manager.createCreationalContext(bean)).toString();
      }
   }
}

Has this ever worked? .toString() just returns as call from Object and there doesn't seem to be a provider agnostic way to enforce the actual instance to be created.

have anyone ever tested this ?

hi, i'm just researching and according to the spec of "ProcessBean" this won't work...
Why the posted solution may not work is that "ProcessBean" is the event right before a bean gets deployed. the call of Object.toString() is because the guy enabled bean discovery mode "all" what lifts all classpath classes up to beans.

EDIT: but you can use the event to gather information about the beans discovered... usually you might be interested in "ManagedBean"s

You can consider using the @initialized qualifier introduced in CDI 1.1 spec, and provided by the Weld implementation.
Here is a demo code: https://gist.github.com/sermojohn/c1044df560dbd86e4b9fae0283c64265