Packaging EJB Applications
This page contains a brief summary about Packaging of EJB applications. It only gives basic information, for more details about life cycle and other functionalities check the EJB 3.0 reference or some book like EJB3 in Action.
What's packaging? To be able to interact with a JEE application you have to put that application inside a JEE container, a process called deployment. But a normal (and reasonably complex) JEE application consists of several pieces: JSF, Session Beans, MDB, JPA and more. To facilitate the deployment process JEE allows you to group these components into files, in a process called packaging. The different files (ear, war, jar) are zip files with a specific structure and a specific extension to indicate the type of contents it has. Each file has a descriptor, an xml file with configuration related to its contents.
These formats and processes are defined in the JEE standard, which means they are completely portable between different servers making sure the code you write will work on any server that follows the standard. They are:
- CAR (client application archives). Descriptor: application-client.xml. Contains: thick Java clients for EJB
- EAR (enterprise application archives). Descriptor: application.xml. Contains: other JEE modules such as WAR and EJB-JAR
- EJB-JAR (EJB Java archives). Descriptor: ejb-jar.xml/persistence.xml. Contains: Session beans and MDB. If it includes persistente.xml then we can add JPA entities
- RAR (resource adapter archives). Descriptor: ra.xml. Contains: Resource adapters
- WAR (web application archives). Descriptor: web.xml/persistence.xm. Contains: Web application. If it includes persistente.xml then we can add JPA entities
Next I will explain the format of EJB-related files (it's a part of the SCBCD exam so pay attention!)
EAR files
An example of a typical EAR file can be:
META-INF/application.xml
file1-ejb.jar
file2.war
file3-client.jar
lib/lib1.jar
lib/lib2.jar
While the contents of application.xml follow a structure similar to:
file1-ejb.jar
file2.war
file2
file3-client.jar
EJB-JAR files
An example of a typical EJB-JAR file can be:
META-INF/MANIFEST.MF
META-INF/ejb-jar.xml
package/*.class
While the contents of ejb-jar.xml follow a structure similar to:
BeanOne
package.BeanOneRemote
package.BeanOne
statelessContainer
BeanOne
*Required
users
Although this is just a small fraction of the possible contents of this file (like interceptor, etc.) you can observe all the values have their counterparts as annotations. Choosing one over another is a matter of taste, although usually annotations make a simpler way of managing the beans (except in cases where we can't hardcode the value). As a matter of fact you can use both at the same time, and any configuration in the descriptor file will override the annotations.
You must be aware the standard don't define some aspects (like the passivation mechanism), leaving them to vendors. That means vendors usually have another descriptor, with a proprietary format, to manage those configurations. For example JBoss uses the "jboss.xml" file. Although the vendors usually provide annotations for those aspects, it's not recommended to use them as that would break the portability of the code. Is better to use the proprietary xml descriptors so you can replace them as needed if you change your container.
Entities
As you may remember entities don't have their own archive file, but they are deployed along EJB or WAR packages. That said, they need their own configuration files so in a package with JPA entities you will find a file named "persistence.xml" in the META-INF folder and the corresponding class files in their packages. You may have a file named "orm.xml" inside META-INF. This optional files describes OR mappings for you files.
The persistence.xml file has a structure similar to:
oracle.toplink.essentials.PersistenceProvider
jdbc/ApplicationDS
secondORmap.xml
entities/EntitiesFile.jar
package.Class1
package.Class2
As you can deduce from the format you can define several persistence units in the same file, and map them to their OR xml files using the mapping-file tag. Those OR xml files have
