How do we configure bean behavior (transactions, security, resource references) without changing Java code? The bean provider shouldn’t hardcode these, and the deployer should be able to configure them at deployment time.
The Deployment Descriptor is an XML file (ejb-jar.xml) that declares how an Enterprise Bean should behave in the container. It configures transaction attributes, security roles, container-managed fields, and other deployment-specific settings declaratively.
- Bean is packaged in EJB-JAR with deployment descriptor (META-INF/ejb-jar.xml)
- Container reads deployment descriptor during deployment
- Container applies configurations to the bean:
- Transaction attributes
- Security roles and permissions
- Container-managed fields (for CMP)
- Resource references (datasources, etc.)
- Descriptor overrides default behaviors
- For EJB 3.x: Many settings move to annotations, but DD still used
- XML-based: Standard format (ejb-jar.xml in EJB 2.x)
- Declarative: No Java code changes needed
- Container-managed: Container interprets and applies
- Transaction attributes: REQUIRED, REQUIRES_NEW, NOT_SUPPORTED, etc.
- Security roles: Who can access which methods
- Portable: Standard format across application servers
- Overridden by annotations in EJB 3.x
- Built from: EJB Container — interprets deployment descriptor
- Configures: Container-Managed Persistence — can specify CMP fields
- Configures: Transaction Attribute — transaction behavior
- Related: EJB JAR — packaging format
- Related: EJB-QL, CDATA Hack, CMT vs BMT, CMP Abstract Accessors, One-to-One, M:N Relationships
- EJB 3.x reduces need for DD with annotations
- Some settings can be specified in both DD and annotations (precedence varies)
- Different servers may have server-specific descriptors
- Descriptor errors can cause deployment failures
- Security: Ensure DD is not world-readable in production