Head First EJB

Chapter 12. A Bean’s Environment: The Joy of Deployment

You worked hard on that bean. You coded, you compiled, you tested. About a hundred zillion times. The last thing you want to touch is already-tested source code, just because something simple changed in the deployment configuration. Maybe the name of the database is different. Maybe you hard-coded a tax-rate (remember—bean’s can’t access property files). And what if you don’t even have the source code? Maybe you got it from Beans-r-Us, and they won’t sell you the source (not on your budget, anyway). EJB supports bean reuse through the Deployment Descriptor and a bean’s special environment.

Objectives

A Bean’s Environment

Official:		What it really means:
13.1	Identify correct and incorrect statements or examples about an enterprise bean’s JNDI naming.	You must know the ways in which a bean can be customized at deployment time, without changing source code. When a bean does a JNDI lookup using the bean’s own special environment, you must know how the code relates to what’s in the deployment descriptor, and a bunch of finicky details that mean the difference between a successful deployment or one that won’t deploy. Or much worse... one that deploys but blows up sometime later, while its running. You need to know what is and is not guaranteed by the EJB 2.0 specification. For example, an EJB 2.0 container is not required to support JXTA, ...