CDI Managed Beans - Glossary

Back to Java Glossary

A	B	C	D	E
F	G	H	I	J
K	L	M	N	O
P	Q	R	S	T
U	V	W	X	Y
Z

In the context of Jakarta EE 9, a CDI Managed Bean is a Java class managed by the Contexts and Dependency Injection (CDI) container, as defined by the CDI specification (JSR 365). CDI is a key component of Jakarta EE that provides a robust dependency injection and lifecycle management framework.
Definition and Characteristics A CDI Managed Bean is a Java object that:

Is instantiated and managed by the CDI container.
Supports dependency injection, allowing other beans or resources (e.g., EJBs, JPA entities, or other CDI beans) to be injected into it using annotations like @Inject.
Has a well-defined lifecycle and scope (e.g., @RequestScoped, @SessionScoped, @ApplicationScoped, etc.), which determines how long the bean lives and how it is shared across different contexts.
Can participate in CDI features like interceptors, decorators, and events for advanced functionality.

Key Features

Automatic Discovery: By default, CDI scans classes in a Jakarta EE application for managed beans. A class qualifies as a CDI managed bean if:
- It is not an EJB (though EJBs can also be CDI managed beans in certain cases).
- It is not an inner class or abstract class (unless explicitly annotated).
- It has a constructor with no parameters or a constructor annotated with @Inject.
- It is in a bean archive (explicit or implicit).
Bean Archives:
- CDI beans are discovered in bean archives, which are JARs or WARs containing a beans.xml file (even if empty) in the META-INF or WEB-INF directory.
- In Jakarta EE 9, the default scanning mode is annotated, meaning only classes with specific CDI annotations (e.g., @Named, @RequestScoped, etc.) are considered managed beans unless overridden in beans.xml.
Annotations:
- Dependency Injection: The @Inject annotation is used to inject dependencies into the bean.
- Scopes: Annotations like @RequestScoped, @SessionScoped, @ApplicationScoped, or @Dependent define the lifecycle and visibility of the bean.
- Qualifiers: Annotations like @Named or custom qualifiers help resolve ambiguities when multiple beans of the same type are available.
- Interceptors and Decorators: CDI managed beans can use @Interceptor or @Decorator for cross-cutting concerns like logging or transaction management.
Lifecycle Management:
- The CDI container manages the creation, injection, and destruction of beans.
- Beans can have lifecycle callbacks like @PostConstruct (called after creation) and @PreDestroy (called before destruction).

Example

import jakarta.inject.Inject;
import jakarta.enterprise.context.RequestScoped;
import jakarta.annotation.PostConstruct;

@RequestScoped
public class UserService {
    @Inject
    private UserRepository userRepository;

    @PostConstruct
    public void init() {
        System.out.println("UserService initialized");
    }

    public String getUserName() {
        return userRepository.findUserName();
    }
}

In this example:

UserService is a CDI managed bean with @RequestScoped, meaning a new instance is created for each HTTP request.
The @Inject annotation injects a UserRepository dependency.
The @PostConstruct method is called after the bean is instantiated and dependencies are injected.

Requirements for a CDI Managed Bean
To qualify as a CDI managed bean in Jakarta EE 9, a class must:

Be a concrete class or annotated with @Decorator or @Interceptor.
Not be annotated with @Vetoed or belong to a package/class explicitly excluded in beans.xml.
Be in a bean archive (implicit or explicit).
Have a no-arg constructor or one annotated with @Inject.

Jakarta EE 9 Context
In Jakarta EE 9, CDI 2.0 (or later) is used, which is part of the Jakarta CDI specification. Key changes in Jakarta EE 9 include:

The shift from javax.* to jakarta.* namespace (e.g., jakarta.inject.Inject instead of javax.inject.Inject).
Enhanced modularity and compatibility with modern Java SE versions.
Continued support for features like dependency injection, event handling, and interceptors, with improved integration with other Jakarta EE components like Jakarta REST (JAX-RS) and Jakarta Persistence (JPA).

Summary: A CDI Managed Bean in Jakarta EE 9 is a Java class managed by the CDI container, enabling dependency injection, lifecycle management, and advanced features like interceptors and events. It is defined by its annotations, scope, and inclusion in a bean archive, making it a core building block for modular, loosely coupled applications in Jakarta EE.

Activate: "When a bean is read into a container from secondary storage and added to the working set, it is known as activation."
API: Application programming interface.
Atomic unit of work: A number of steps that must all be executed or none of them executed.
Bean factory: That part of an object monitor that is responsible for creating (manufacturing) the bean when required.
Bean handle: A universal reference to a bean instance, that is available from the EJBObject, that can be used to re-connect to a bean at a later time.
Bean interface: The interface that specifies the bean's business methods.
Begin transaction: Start a transaction. All steps that follow until either commit or rollback will be treated as an atomic unit of work.
Bluetooth: Bluetooth is an industrial specification for wireless personal area networks (PANs). Bluetooth provides a way to connect and exchange information between devices like personal digital assistants (PDAs), mobile phones, laptops, PCs, printers and digital cameras via a secure, low-cost, globally available short range radio frequency.
Builder tool: A tool that allows the combining of client side JavaBeans into sophisticated applications with little or no programming.
Callback: A method in a bean that will be called by its container for some particular purpose.
CDI Managed Bean: A CDI Managed Bean is a Java class whose lifecycle and dependencies are automatically managed by the Jakarta EE container through the Contexts and Dependency Injection (CDI) specification. The container handles the instantiation, injection of dependencies, and destruction of these beans, which are typically identified by a scope annotation like `@ApplicationScoped` or `@RequestScoped`.
Client: In the CDI paradigm, managed beans are designed to be reusable components that can be injected into various parts of an application. The object that receives this injection is considered the "client" of that bean.
Client program: A program that is written that uses the services of a remote object.
Commit transaction: Make the changes requested in the steps since the begin transaction permanent.
Component: A physical and replaceable part of a system that conforms to and provides a realization of a set of interfaces.
Concurrency: "In multi-threaded systems, an object that could have one or more threads executing its methods and changing its state at the same time is said to be concurrent and to exhibit concurrency.
Container: That part of a object monitor that manages the remote object and provides system services.
CORBA: The common object request broker architecture that allows clients to find servers and invoke their methods.
Deploy: Add a remote object to an Object Monitor so that it is available to clients.
Deployable unit: A deployable unit is a jar file for an EJB that contains the bean's class files and the DD used for software distribution.
Deployment descriptor: Information that describes both the structure of an Enterprise Java Bean, and the information required by it at runtime.
Design pattern: A generalized solution to a common frequently occurring object oriented design problem.
Distributed application: An application built from interacting remote objects.
Distributed object: An object somewhere on the network, that provides some service, that is known and available to clients.
Distributed system: A system made up of one or more applications that are built from interacting clients and remote objects.
Distributed transaction: If a transaction is started on a specific system and all requests to other remote objects maintain and propagate that transaction, the environment is said to support distributed transactions.; Copy a file from a common resource to the local environment.
EJBObject: That skeleton of the bean that implements the bean's interface.
Entity bean: An EJB that is an object representation of a piece of persistent data.
Environment: The information that is part of the instance's context, used at runtime, that is set in the deployment descriptor and accessed through the EJBContext object.
Handle: An object which contains all the information required to access an existing remote session bean.
Home interface: The Java interface that is implemented by the deployer to build the home object.
Home object: The EJB bean factory (see above). It listens on the network for client create() and remove() requests.
IIOP: The internet inter-orb protocol used by CORBA to communicate between CORBA clients and servers.
Implement: An object that provides a realization of a particular interface is said to implement that interface.
Instance: "An object. When a class is instantiated to produce an object, we say that the object is an instance of the class."
Instance's context: "Runtime information that is made available to the instance of the bean by the container. It includes security, transaction and environment information. "
Interface: The public methods of an object that provide some useful service.
J2EE: "Java 2 Enterprise Edition - includes EJBs, Servlets and Java Server Pages."
Jar file: A file created with the Java jar program which is similar to tar on the Unix platform.
Javadoc: The program that creates the HTML based documentation that is provided as part of the SDK.
JVM: The Java Virtual Machine, a software implementation of a portable environment, that executes Java programs.
Lifecycle: The states that an object can be in from its birth to its death.
Local resource: A resource, such as a database connection, that is accessible without traversing the network.
Lookup: The looking up of a service provided by the remote object in a name service.
Loopback: "When a bean, within and method, invokes its own methods, directly or indirectly it is known as a loopback."
Marshal: The translation of a method call with its parameters into a wire format suitable for transmission of a network transport. See un-marshalling.
Message: Another name for a method call. Conveys the idea that the method call is invoked across a network
Metadata: "The information about an object: its methods, parameters, return types, etc."
Middleware: Software systems and utilities that provide a service and sit between the client and backend databases or legacy systems.
Naming service: An entity that provides a lookup service to enable clients to find specific remote objects.
Network address: The information that is required to access the skeleton of a remote object somewhere on a remote host.
Network transport: Another name for a network and its associated protocols.
no-arg: A method that takes no arguments. For example create() in the home interface.
Object monitor: The combination of remote object together with the environment that manages it and that allows method calls to the remote object. Object Monitors are CORBA-based solutions that let programmers write applications based on reusable object-oriented components-applications that can run transactions across multiple networks.
Object semantics: "The term implies that the objects have typical behavior as implemented in programming languages such as Java, C++ and SmallTalk."
Passivate: A container stores a bean on secondary storage to reduce its working set; this is known as passivation.
Persistence: Objects whose state lives beyond the lifetime of the object are known as persistent. The state is usually stored in a database.
Plumbing: A colloquial term for the set of system services that are available to a remote object.
Proxy pattern: A pattern, for implementing access to remote objects, that provides a local object having the same interface as the remote object.
Realization: The concrete implementation of one or more interfaces.
Remote interface: The Java interface that is used by the deployer to build the EJBObject.
Remote object: An object that provides a service through its methods and is located on another host on the network. The location of the object needs to be known before its methods can be called.
Remote reference: "The reference to an object, usually the stub, that knows where, and how to communicate with, a remote object."
RMI-IIOP: "The protocol, based on IIOP, that is planned for the implementation of RMI."
Rollback transaction: Undo any changes requested in the steps since the begin transaction.
Security: In this course security relates to client access to a remote object only.
Serializable (1): The ability to convert from object semantics to a wire format.
Serializable (2): "When multiple invocations of a method must be invoked one by one in sequence, this is known as serialization."
Server: That part of a object monitor that handles networking and distributed services.
Service: "To be useful, a remote object must perform some useful function. This function is know as the ""service"" it provides. "
Session bean: An EJB that has a 1 to 1 relationship with its client.
Skeleton: "The object that listens on the network for requests to a specific remote object from a client, then invokes those methods and returns any return value back to the client."
Stateful: The property of an object such that it contains information that is maintained across method calls.
Stateless: The property of an object such that it contains no information that needs to be preserved across method calls.
Stub: The object that the client uses to make requests of a remote object
Transaction: A transaction is a unit of work that comprises some input request, the processing of that request and the return of a response to the request.
Transaction aware: An environment that supports transactions.
Transaction management: Managing multiple operations in an object such that they all are executed or none are executed. This ensures consistent state of the underlying persistent information.
Transient: A label, applied to an instance variable of a bean, that instructs Java serialization to ignore that variable.
Transport: See network transport.
Tuple: A expression that contains a pair of relate objects.
Un-marshaling: The translation of a method call back to object semantics from the wire format used to transmit it across the network.
Upload: Copy a class or a file to a common resource such as the name service.
Wire format: The format of a method call when translated into bytes suitable for sending over a network.
Working set: The number of beans a container can manage in memory concurrently.
XML: Extensible markup language; used to describe and transport information (data).