Before a Java EE application can be used it must be deployed to a server. The process of deployment consists of packaging the components of the application together and then installing these components on a server. Once they are installed, individual classes are loaded into memory. This process can be complicated; however, the deployment descriptors examined in this chapter provide additional opportunities for tailoring an application for specific servers and making applications more portable and maintainable.

The packaging of a Java EE application is accomplished using Java ARchive (JAR) files. These files are stored in ZIP format and contain the classes and resources needed by the application. In Java EE, there are specialized versions of the JAR files including EAR, WAR, and EJB-JAR.

The deployment process is controlled by deployment descriptors. These files specify how the application should be installed and how many of the behavioral characteristics of a component, such as how transactions are handled or which roles can access a component. In the context of EJB development roles, the management of deployment descriptors is the responsibility of the application assembler. In a larger organization, an individual may be tasked with the assembly of EJB JAR and WAR files into EAR files. The individual would also be responsible for configuring the deployment descriptors for the application.

Annotations or elements of a deployment descriptor can be used to configure an EJB. Annotations are easy to use but may not be the best choice if application settings change frequently. Hard coding names for JNDI and JMS resources will require the code to be re-compiled if they change. Also, some settings such as specifying default interceptors cannot be done using annotations.

While there is some argument as to which approach is best, you are free as a developer to use the most appropriate approach for your application. In general, annotations are better suited for static environments while deployment descriptors are better suited for dynamic environments. The approaches can be intermixed. When this happens, deployment descriptors override annotations.

Some annotations cannot be overridden:

Deployment descriptors are optional in Java EE 5 and later. When a deployment descriptor is not present, the server determines the makeup of the application by examining the contents of the JAR files and using a standard naming convention as detailed in http://java.sun.com/blueprints/code/namingconventions.html.

A Java EE application typically consists of many different types of components including EJBs, HTML, JSP, and servlets. EJBs execute from within an EJB container while servlets execute from a web container. These components can be packaged in different JAR files. The various packaging types include:

Entities can be deployed in most JAR files except RAR modules. When entities are packaged in a file, a persistence.xml file is frequently placed in the JAR file also.

An important aspect of deployment and the execution of the application is the class loading process. The Understanding class loading recipe addresses this issue.

Chapter 8, Interceptors details the creation and use of interceptors. There are several kinds of interceptor methods and these can be configured using a deployment descriptor:

We also examine the use of deployment descriptors for transactions and security in the Using a deployment descriptor for transactions and Using deployment descriptors for security recipes respectively.