Extending the Power of Jakarta EE and MicroProfile With CDI Extension

One of the reasons the market adopted Java so firmly is the power of the environment around it: the ecosystem is enormous. We have at least two or more frameworks to work on multiple proposals, besides the platforms where it assembles several solutions to work as one, such as Spring, Quarkus, Jakarta EE, and MicroProfile. 

Looking deep into both Jakarta EE and MicroProfile, we have a glue, the CDI, which guarantees consistency and the perfect harmony around both solutions. 

It happens thanks to the CDI extension's CDI feature that allows the engine to be more extensible. It will enable CDI to integrate with other technologies. If you look at a new specification on both Jakarta EE and MicroProfile, it should have a CDI extension to make it work.

By specification, the design of the portability of CDI allows you:

• Integration with business process management engines
• Integration with third-party frameworks such as Spring, Seam, GWT, or Wicket
• New technology based upon the CDI programming model

Yep, we have a powerful ally to create and increase those platforms or even use CDI alone. 

By default, CDI works lazily. Therefore, it will instance only if it is necessary. A sample of CDI extension will create an annotation to start the bean eagerly.

@ApplicationScoped
public class LazyBean {
    @PostConstruct
    public void setUp() {
        System.out.println("Application starting up on the lazy way");
    }
    public void action() {
        System.out.println("Let me do something");
    }
}

Usually, it performs like a charm. However, there are scenarios where we want to start eagerly, such as a long start-up with extensive database operations where it does not make sense to create a process only when the user requests it. The goal is to make it ready and available when it is prepared.

The first step in the start-up sample is creating a StartUp annotation.

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD, ElementType.FIELD})
public @interface Startup {
}

Once we have the annotation, the next step is to make it work. The extension works by implementing an Extension interface and observing an event. Each event is fired on a different lifecycle in this order:

• BeforeBeanDiscovery
• ProcessAnnotatedType and ProcessSyntheticAnnotatedType
• AfterTypeDiscovery
• ProcessInjectionTarget and ProcessProducer
• ProcessInjectionPoint
• ProcessBeanAttributes
• ProcessBean, ProcessManagedBean, ProcessSessionBean, ProcessProducerMethod, ProcessProducerField and ProcessSyntheticBean
• ProcessObserverMethod and ProcessSyntheticObserverMethod
• AfterBeanDiscovery
• AfterDeploymentValidation

On the extension implementation, StartupBeanExtension, we'll use two events: ProcessBean and AfterDeploymentValidation, where we'll check the annotation ApplicationScoped and then initialize the bean.

public class StartupBeanExtension implements Extension {

    private final Set<Bean<?>> startupBeans = new LinkedHashSet<>();

    <X> void processBean(@Observes ProcessBean<X> event) {
        if (event.getAnnotated().isAnnotationPresent(Startup.class)
                && event.getAnnotated().isAnnotationPresent(ApplicationScoped.class)) {
            this.startupBeans.add(event.getBean());
        }
    }

    void afterDeploymentValidation(@Observes AfterDeploymentValidation event, BeanManager manager) {
        for (Bean<?> bean : startupBeans) {

            manager.getReference(bean, bean.getBeanClass(), manager.createCreationalContext(bean)).toString();
        }
    }
}

The last step is registering this extension as an SPI; therefore, create a file jakarta.enterprise.inject.spi.Extension and then put the implementation there. 

We can make an analogy where the Java SPI is the glue to the Java core as CDI is the glue to Jakarta EE and MicroProfile platforms. The SPI is an animated feature that allows more extensibility on the code; it does not belong to the CDI but to the Java core. 

In this video, we'll explore the CDI extension feature to make CDI even more extensible and allows for an increase in the platform. It will use a simple example to start a bean eagerly using this CDI.