Write the code to lookup a bean using its primary key.
Locating Enity Bean
In Jakarta EE 10, Entity Beans from J2EE (EJB 2.x) have been fully replaced by Java Persistence API (JPA), which offers a more flexible, modern, and POJO-based approach to persistence. The concept of locating an entity bean using a primary key has been modernized using JPA's `EntityManager` and its method:
<T> T find(Class<T> entityClass, Object primaryKey);
✅ How Primary Key-Based Lookup is Replicated in Jakarta EE 10 (Using JPA)
Instead of using JNDI lookups or `home.findByPrimaryKey()` as in J2EE Entity Beans, in Jakarta EE 10 you do the following:
✅ Step-by-Step Comparison
J2EE (Entity Beans)
Jakarta EE 10 (JPA)
Requires remote/local interface
POJOs annotated with @Entity
home.findByPrimaryKey(primaryKey)
entityManager.find(Entity.class, primaryKey)
Container-managed persistence and lifecycle
You manage persistence with EntityManager
EJB deployment descriptors (XML)
Uses annotations like @Entity, @Id, @GeneratedValue
✅ Example in Jakarta EE 10 (JPA-based): Entity Class:
import jakarta.persistence.*;
@Entity
public class Customer {
@Id
private Long id;
private String name;
// getters and setters
}
Stateless Bean or CDI Bean:
import jakarta.persistence.*;
import jakarta.ejb.Stateless;
@Stateless
public class CustomerService {
@PersistenceContext
private EntityManager entityManager;
public Customer findCustomer(Long id) {
return entityManager.find(Customer.class, id);
}
}
✅ Key Benefits Over J2EE Style
No need for home interfaces
No JNDI lookups
Entity lifecycle managed via `EntityManager`
Annotations make entity configuration simpler and type-safe
Summary: The primary key lookup of entity beans in J2EE is now cleanly replicated and improved in Jakarta EE 10 through JPA's `EntityManager.find()`. This is more maintainable, testable, and integrates seamlessly with the CDI and EJB architecture.
The diagram titled "EntityManager.find() Process" outlines the steps for retrieving an entity from a database using JPA in Jakarta EE 10.
Here's the detailed breakdown of each step:
@Entity class
Define a plain Java class and annotate it with `@Entity`.
This marks the class as a JPA-managed entity that maps to a table in the database.
Example:
@Entity
public class Customer {
@Id
private Long id;
private String name;
}
Inject EntityManager
Use the `@PersistenceContext` annotation to inject an instance of `EntityManager` into a managed bean (like a `@Stateless` EJB or CDI bean).
This `EntityManager` is used to interact with the persistence context.
The `find()` method returns the entity object if found, or `null` if no matching row exists in the database.
The returned object is managed by the current persistence context.
Summary: This process replaces complex EJB Entity Bean lookup with a clean, annotation-driven, POJO-based approach using `EntityManager.find()` in Jakarta EE 10 with JPA. It simplifies database interaction while adhering to modern standards.
JPA entities are simple POJOs
In Jakarta EE 10, the term "entity bean" (from the old EJB 2.x model) is deprecated and no longer used.
Instead, we use JPA entities, which are simple POJOs (Plain Old Java Objects) annotated with `@Entity`.
🔄 Terminology Shift
Legacy Term (J2EE)
Modern Jakarta EE 10 Term
Entity Bean
JPA Entity
Home Interface
EntityManager.find()
Deployment Descriptor
Annotations (@Entity, @Id, etc.)
Container-managed Fields
POJO fields with annotations
✅ JPA Entities ≈ ERD Entities
JPA entities are aligned with ERD (Entity-Relationship Diagram) concepts:
In ER modeling, an entity maps to a table.
In JPA, an `@Entity` maps to a table.
Each field in the entity corresponds to a column.
The `@Id` field maps to the primary key.
🧠 Example Mapping
ERD Table: `Customer(id, name, email)`
JPA Entity:
@Entity
public class Customer {
@Id
private Long id;
private String name;
private String email;
// getters/setters
}
In Jakarta EE 10, you are still modeling *entities", just with a more lightweight, modern, and decoupled architecture compared to the old EJB-based system.
For J2EE which was used during the dotcom era, the server side application would use a primary key to locate an entity bean?
Has the use of entity beans in Jakarta EE 10 been deprecated.
Describe the server side Java technology which is used to locate the primary key of a MySQL database table.
Finding the data
If the client knows the primary key of the persistent data that it needs, it can use that primary key to look up the bean.
The home object has a method findByPrimaryKey(PrimaryKey) that is used to create an instance of the bean and initialize it with the persistent data. The mechanism is described in the following series of images.
How do you find an entity bean using the primary key?1) The client invokes the findByPrimaryKey() method of the home object passing it the primaryKey object.
2) The container creates an instance of the bean and asks it to look up the data.
3) The instance looks up the data and, if the key matches some data, the data is read into the bean instance.
4) The bean instance returns control to the container.
5) The container creates an EJBObject for the primary keys.
6) The home object returns the EJBObject remote reference to the client. The client can then access the bean instance for that primary key.
Transition from Legacy J2EE to Jakarta EE
The `EJBObject` interface was part of the EJB 2.x remote invocation model, which required:
A remote interface that extended javax.ejb.EJBObject
Explicit use of RMI/IIOP
Use of JNDI lookups to obtain the stub object
Example (legacy J2EE):
public interface CustomerRemote extends EJBObject {
public String getName() throws RemoteException;
}
❌ Deprecated and Removed
As of EJB 3.x, and continuing into Jakarta EE 10, this model has been completely replaced by a simpler POJO-based, annotation-driven model.
`javax.ejb.EJBObject` is not used or required for any modern enterprise bean.
Instead, remote and local interfaces are defined as plain interfaces using `@Remote` or `@Local`.
✅ Modern Jakarta EE 10 Alternative
@Remote
public interface CustomerService {
String getName();
}
@Stateless
public class CustomerServiceBean implements CustomerService {
public String getName() {
return "Alice";
}
}
No need for EJBObject, EJBHome, or RMI stubs.
Clients invoke methods via dependency injection or portable JNDI names.
✅ Jakarta EE 10 API Confirmation
The Jakarta EE 10 API (jakarta.ejb) does not include `EJBObject`. The Jakarta platform has officially removed legacy EJB interfaces and deployment models tied to CORBA and heavy container contracts.
You can verify this directly via the Jakarta EE 10 API documentation:
jakarta.ejb package
`EJBObject` is not listed.
✅ Summary
✅ EJBObject was required in EJB 2.x (J2EE)
❌ It is not present in Jakarta EE 10
✅ Modern beans use annotations (`@Stateless`, `@Stateful`) and plain interfaces
✅ Clients interact directly with beans or through lightweight dependency injection / JNDI
Subsequent client access
The bean instance for that data now exists. If any client subsequently invokes the findByPrimaryKey() method on the home object, passing it the existing primary key, then the container simply returns the remote reference to the EJBObject.
There is no lookup in the database or creation of a new instance or EJBObject. It is very efficient. The following diagram illustrates what happens:
The diagram you provided illustrates the legacy architecture of EJB 2.x Entity Beans (used during the J2EE era). Here’s a detailed breakdown of each component shown in the image:
🔸 Clients (Client-A and Client-B)
These are remote or local application clients attempting to interact with enterprise business logic and persistent data.
They rely on JNDI lookups to access remote interfaces and invoke business methods on entity beans.
🔸 Home Object
This is an instance of the Home Interface, which is responsible for:
Creating, finding, and removing entity beans.
Returning a reference to an `EJBObject` stub.
Example (J2EE):
CustomerHome home = (CustomerHome) ctx.lookup("CustomerHome");
Customer customer = home.findByPrimaryKey(id);
🔸 EJBObject
Acts as the remote interface proxy, through which the client interacts with the actual entity bean instance inside the container.
Every method on the remote interface is implemented by the EJBObject.
Ensures RMI-style remote communication between the client and server.
🔸 Entity Bean
A server-side component that:
Represents persistent data in a DBMS.
Is managed by the EJB container.
Follows container-managed persistence (CMP) or bean-managed persistence (BMP).
One entity bean corresponds to one row in a relational database table.
🔸 Container
* The EJB container is responsible for:
Managing the life cycle of entity beans.
Providing services like transactions, security, and persistence.
Instantiating and pooling entity beans.
Handling method invocations from EJBObject to the actual bean.
🔸 DBMS (Database Management System)
The underlying relational database that stores the actual entity data.
The entity bean performs CRUD operations on the DBMS either directly or via container-managed mechanisms.
🔄 Summary of the Flow
Client-A performs a JNDI lookup to get the Home Object.
The Home Object provides a reference to an EJBObject via a finder or create method.
The EJBObject serves as the client’s handle to the entity bean.
The entity bean interacts with the DBMS to retrieve or update data.
❌ Deprecated Architecture
EJBObject, HomeObject, and Entity Beans in this form are obsolete as of EJB 3.0 and fully removed in Jakarta EE 10.
They have been replaced by:
POJO-based JPA entities for persistence
Stateless CDI or EJB beans for business logic
No requirement for remote interfaces or RMI
Jakarta EE 10 Architecture
Finding Entity Bean - Quiz
Take a moment to test your knowledge on finding an entity bean using the primary key by clicking the Quiz link below. Finding Entity Bean - Quiz
The next lesson introduces Bean-Managed Persistence (BMP).