Jakarta CDI

Jakarta CDI
Name	Jakarta CDI
Developer	Eclipse Foundation / Jakarta EE
Initial release	2006
Latest release	4.x
Programming language	Java (programming language)
Platform	Jakarta EE platform
License	Eclipse Public License

Jakarta CDI Jakarta CDI is a set of specifications for dependency injection and contextual lifecycle management within the Jakarta EE platform. It defines services used by Jakarta RESTful Web Services, Jakarta Faces, and Jakarta Persistence to perform injection, interception, and event notification across Java (programming language) components. The specification evolved from earlier work in Context- and Dependency-Injection for Java EE and is maintained under the Eclipse Foundation governance model alongside Jakarta EE Platform releases.

Overview

Jakarta CDI provides a standardized programming model for bean discovery, contextual references, and type-safe dependency injection that integrates with JavaServer Faces (JSF), JAX-RS, and EJB components. It replaces vendor-specific injection mechanisms used by GlassFish, WildFly, Apache TomEE, and IBM WebSphere Liberty with a portable model. CDI defines scopes such as @RequestScoped, @SessionScoped, and @ApplicationScoped and supports interceptors modeled after AOP patterns popularized by frameworks like Spring Framework.

Core Concepts

CDI centers on core abstractions: beans, contexts, qualifiers, producers, disposers, interceptors, decorators, and events. A bean is a managed object similar to a component in JavaBeans and can be discovered automatically by the container used in servers such as WildFly or GlassFish. Qualifiers are annotations used to disambiguate injection points in the manner of @Qualifier patterns seen in Google Guice. Producers and disposers enable factory-style creation akin to Factory pattern implementations found in Apache Commons utilities. The event model allows loose coupling between publishers and observers similar to patterns used in Observer pattern implementations like those in Eclipse IDE plugin systems.

Architecture and Components

The CDI architecture defines a container runtime that manages bean lifecycles and contexts, integrating with application servers such as Payara Server and Open Liberty. Key components include the bean manager interface, the injection point abstraction, and portable extensions. Interceptors and decorators are implemented using metadata processed by the container during deployment, much like the bytecode enhancement techniques used by Hibernate ORM. The specification references classpath scanning and discovery strategies used by build tools such as Maven and Gradle (software), and integrates with classloading models defined by OSGi in modular environments.

Usage and Examples

Developers annotate POJOs with CDI annotations to request injection and lifecycle behavior in frameworks such as Jakarta Faces and Jakarta RESTful Web Services. Typical examples include injecting a service into a REST resource hosted by JAX-RS or a backing bean in JSF with annotations familiar from Java EE patterns. Programmatic APIs exposed by the bean manager are used by portable extensions in libraries like DeltaSpike and Weld SE to perform advanced operations such as dynamic bean registration and metadata inspection. CDI event delivery is used in applications integrating with Jakarta Messaging (JMS) to decouple producers and consumers.

Integration with Other Jakarta EE Specifications

CDI is designed to interoperate with Jakarta Persistence for transactional repositories, with JTA for transaction boundaries, and with Jakarta Security for identity propagation into request-scoped contexts. It is the glue between Jakarta RESTful Web Services resources and Jakarta Server Faces view components, enabling injection into Servlet filters and listeners defined by the Jakarta Servlet specification. CDI portable extensions are commonly used by implementations of Bean Validation and integration libraries for JMS brokers like Apache ActiveMQ and Eclipse Mosquitto in microservice architectures orchestrated by Kubernetes.

Configuration and Extensions

Configuration of CDI is driven by annotations and deployment descriptors such as beans.xml, and customization is possible via portable extensions using the CDI SPI. Runtime behavior can be influenced by container-specific configuration provided by WildFly, GlassFish, Payara, or Open Liberty. Extensions like Arquillian testing adapters and Weld portable extensions provide integration points for JUnit and TestNG test suites. Producers and qualifiers allow per-deployment customization similar to resource adapters used by Jakarta Connector Architecture.

Implementations and Compatibility

Major CDI implementations include Weld (by JBoss), OpenWebBeans (by Apache Software Foundation), and GlassFish CDI integration in Eclipse GlassFish. Compatibility is maintained through the Jakarta EE Compatibility Process and tested in certification suites run by vendors like Red Hat and IBM. Version mapping aligns CDI versions with Jakarta EE platform releases and aligns with JVM versions supported by Oracle JDK and OpenJDK distributions. Container vendors provide integration testing with project ecosystems such as MicroProfile.

Security and Best Practices

CDI security considerations focus on preventing unauthorized injection of privileged beans, ensuring proper scope usage to avoid leaking state across sessions, and validating producer methods to prevent unsafe object creation commonly addressed in secure coding guidelines from OWASP. Best practices include preferring constructor injection for immutability in components used by Jakarta Security flows, scoping beans conservatively in web tiers that use Jakarta Faces, and leveraging interceptors for audit trails in compliance scenarios covered by standards like ISO/IEC 27001. Testing with Arquillian and static analysis tools from SpotBugs helps maintain robustness.

Category:Jakarta EE specifications