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.
Declares the made-up JNDI names in the Deployment Descriptor, for the Deployer.
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.