It’s simple... if the programmer puts a made-up JNDI name in code, he has to announce that to the deployer in the DD.

The Deployer has no clue what the Bean Provider put in code, unless the Bean Provider:

A. Tells him.

B. Writes the names on a sticky note and sticks it on the Deployer’s monitor

or

C. Declares references in the Deployment Descriptor, complete with helpful descriptions that make it very clear what the Deployer is supposed to map to the programmer’s made-up names.

image with no caption

Declares the made-up JNDI names in the Deployment Descriptor, for the Deployer.

image with no caption

Maps the programmer’s made-up/fake names to the REAL JNDI names under which the resources were deployed or configured into the server.

Environment entries: deploy-time constants

Imagine you’re writing a simple checkout bean for an online shopping cart system. You don’t know where that bean might end up. Even if you do, you know that things like tax rates and discount policies can change, even within the same company.

Environment entries let you write your code using a variable that you’ll fill in at runtime using a JNDI lookup. Remember, the Bean Provider chooses the name, and it’s up to the Deployer to fill in the value.

Note

this is the part of the lookup that must go in the DD

in a bean’s business method:

in the Deployment Descriptor

Note

The ...

Get Head First EJB now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.