Being a server that implements the complete J2EE 1.4 specification, Geronimo can run and manage a variety of different J2EE application components. All J2EE applications are composed of distinct software components.
In general, these applications or software components are bundled up in archive files (typically using a JAR-type utility), together with the appropriate required J2EE deployment descriptor (XML files).
The J2EE 1.4 software components that can be deployed to and executed on Geronimo include the following:
Java Server Pages (JSP)
Servlets and support Java classes
EJBs of all varieties, including stateless sessionless beans, entity beans, Bean Managed Persistence (BMP), Container Managed Persistence (CMP and CMP2)
Message Driven Beans (MDBs)
JCA-compliant connectors, including JDBC connectors to relational database management systems (RDBMSs), and JMS connectors to message queue (MQ) servers
Table 2-2 shows these application components and the associated deployment packaging.
Application Component | Deployment Packaging |
---|---|
JSP | Part of a WAR (Web application archive) file |
Servlets | Part of a WAR file |
EJB | Either as standalone grouping in an EJB JAR file, or as part of an EAR (enterprise application archive) |
MDB | Same packaging alternatives (as the previous EJB) |
JCA | connectors In a RAR (resource archive) file |
Before application components can be deployed to Geronimo, they must be packaged into standard archives and must include standard deployment descriptors as described in the next section.
Deployment descriptors are XML files that contain information regarding the software component being deployed. There are generally two types of deployment descriptors:
Standard J2EE deployment descriptors
Geronimo-specific (vendor-specific) deployment descriptors
In the progeron.ear deployment example, you have only used the standard J2EE deployment descriptors. This is because Geronimo is designed to be able to deploy many J2EE applications without the need for vendor-specific deployment descriptors. This is a great feature, because it means that you can deploy the same EAR bundle to any compatible server (or even different versions of the same server) without having to create vendor-specific plans.
Important | The terms deployment descriptor and deployment plans are used interchangeably throughout this book. You will tend to see the use of deployment descriptors in referring to J2EE standard plans, while the use of deployment plan is more appropriate for vendor-specific plans. |
Table 2-3 enumerates the standard J2EE deployment descriptors required in the respective archive files.
Packaging Archive File | Standard Deployment Descriptor |
---|---|
WAR file | A web.xml file in the WEB-INF subdirectory |
EAR file | application.xml in the META-INF directory |
EJB JAR file | ejb-jar.xml in the META-INF directory of the JAR file |
RAR file | ra.xml in the META-INF directory |
Most likely, you will be configuring and deploying WAR and EAR files regularly. These are the typical distribution unit output from development teams. Every change of application-level code by the development team will involve the construction of a new WAR or EAR archive.
You use a standalone EJB JAR archive when EJBs are deployed in isolation and not as a part of a bigger enterprise application. This may occur, for example, if you are deploying EJBs for access by multiple Web-tier WARs or directly by EJB client applications. However, you will almost always find EJB JAR files as part of an EAR archive.
RARs are connectors that are typically supplied by enterprise information system (EIS) server vendor. For example, a JDBC connector is supplied by the RDBMS vendor. Resources in RAR files seldom change. Because of this, the deployment of RARs will typically be infrequent.
Important | This brings up one interesting behavior of the Geronimo server. Applications or components deployed to Geronimo are persistent. That is, once you have deployed it, Geronimo will remember it. Even if the server is rebooted, the deployed application is still kept by Geronimo and the server will attempt to restart the application or component the next time it restarts. |
Given that components deployed to Geronimo are persistent, there is no need to redeploy a set of components (forming an application) once they are deployed. Typically, in a production situation, you will only need to redeploy an application when there is a new release of the application.
Some of the Geronimo-specific deployment descriptors that you may use include descriptors that are often called deployment plans (see Table 2-4).
Package Archive File | Geronimo-Specific Deployment Plan |
---|---|
WAR | geronimo-web.xml under WEB-INF, alongside the required web.xml descriptor |
EAR | geronimo-application.xml under META-INF, alongside the required application.xml descriptor |
JAR | openejb-jar.xml under META-INF, alongside the required ejb-jar.xml descriptor |
RAR | geronimo-ra.xml under META-INF alongside the ra.xml descriptor |
These Geronimo-specific deployment plans are not always required. They provide additional deployment control and application run-time configuration above and beyond those offered by standard J2EE descriptors. Chapters 9 to Chapter 15 will provide more details on these plans. For now, it is sufficient to know you may need one of more of them when you deploy your applications in production.
In addition to server-side support, Geronimo also provides J2EE client support. J2EE client code can be bundled in client JAR file and deployed with Geronimo as a client container. The Geronimo-specific deployment plan in this case is called geronimo-client.xml and should be placed in the META-INF directory of the JAR archive containing the J2EE client code. J2EE client support in Geronimo 1.1 is limited, since the client using this support is restricted to running on the same host as the server itself. This limitation is expected to be lifted in a future release.
To be totally flexible with deployment, Geronimo will accept a deployment plan that is specified during the deployment process. This means that the Geronimo-specific deployment plan need not be bundled in as part of the archive. This makes it possible to create a generic EAR file that can be deployed on multiple J2EE servers and add the Geronimo-specific details at deploy time.