{scrollbar}

Every module that you install in Geronimo, whether it is a service, application, resource, etc., can be configured via a deployment plan. These deployment plans are XML files based on XML Schemas containing the configuration details for a specific application module or component. The Java EE 5 specification defines standard deployment descriptors such as web.xml, application.xml, etc. In some cases, the deployment descriptor is all that is required to install a module into a Geronimo server. However, in many cases, server-specific configuration is required when modules are installed. This server-specific configuration is accomplished by using Geronimo deployment plans.

Geronimo deployment plans can be packaged along with the application or specified externally at deployment time. If provided during deployment, this plan will overwrite any other Geronimo specific deployment plan provided with the application.

To package the deployment plans in you application you have to follow some naming conventions and place the file in a specific directory within your packaged application. For example, in a web application you would include the geronimo-web.xml under the /WEB-INF directory, same place where you are also providing the web.xml descriptor, all within the WAR. For an enterprise application you would include the geronimo-application.xml under the /META-INF directory, same place where you are also providing the application.xml descriptor, all within the WAR.

The Java EE 5 specification also let's you use Annotations where you add resource references, dependencies, etc. directly in the code. Geronimo provides a Deployment plan wizard that automatically generates the necessary deployment plans based on the standard deployment descriptors and annotations.

This document is organized in the following sections:

XML Schemas

Java EE Deployment Plans

Common Elements & Configuration

Configurations

The examples provided in this section are independent of any application. Most of these configurations can be generated and deployed through the Geronimo Administration Console as well.

Connection pools

For the most part, deployment plans for database connection pool will be very similar from each other. However, depending on the database the pool will be connecting to, you may need to specify some additional parameters.

Embedded Derdy DB

...

<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.2">
    <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
        <dep:moduleId>
            <dep:groupId>console.dbpool</dep:groupId>
            <dep:artifactId>TimeReportPool</dep:artifactId>
            <dep:version>1.0</dep:version>
            <dep:type>rar</dep:type>
        </dep:moduleId>
        <dep:dependencies>
            <dep:dependency>
                <dep:groupId>org.apache.geronimo.configs</dep:groupId>
                <dep:artifactId>system-database</dep:artifactId>
            </dep:dependency>
        </dep:dependencies>
    </dep:environment>
    <resourceadapter>
        <outbound-resourceadapter>
            <connection-definition>
                <connectionfactory-interface>javax.sql.DataSource</connectionfactory-interface>
                <connectiondefinition-instance>
                    <name>TimeReportPool</name>
                    <config-property-setting name="Driver">org.apache.derby.jdbc.EmbeddedDriver</config-property-setting>
                    <config-property-setting name="ConnectionURL">jdbc:derby:TimeReportDB</config-property-setting>
                    <connectionmanager>
                        <local-transaction/>
                        <single-pool>
                            <max-size>10</max-size>
                            <min-size>0</min-size>
                            <match-one/>
                        </single-pool>
                    </connectionmanager>
                </connectiondefinition-instance>
            </connection-definition>
        </outbound-resourceadapter>
    </resourceadapter>
</connector>

Security

A Java EE application may consist of several components that can be deployed on to different containers such as WEB container, EJB container, WebServices container in a JEE5 server. This kind of deployment allows multi-tier applications that interact with one another to perform a given user task. Multi-tier JEE5 applications can be secured by properly selecting authenticating mechanisms and designing authorization levels or roles. If the application components use declarative security management, the authentication and authorization aspects are declared in corresponding JEE5 deployment descriptors. The declared security roles or levels are mapped to real security roles or levels in the geronimo deployment plans through security realms. In apache geronimo , the security realms abstract away authentication and authorization aspects of the application components. The authentication and authorization together enable access control for the various components of the application.

Depending on the selected authenticating system, a JAAS login module is selected and configured in a security realm. JAAS login modules connect to corresponding user/group repositories and perform authentication and retrieve authorization information. The geronimo server provides login modules that connect to different types of user/group repositories. These are PropertiesFileLoginModule, LDAPLoginModule, SQLLoginModule and CertificatePropertiesFileLoginModule.

For example, geronimo uses geronimo-admin security realm to authenticate users when they login to the geronimo administration Console. The deployment plan of the security realm is follows.

geronimo-admin security realm

...

<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2">
     <environment>

         <moduleId>
             <groupId>console.realm</groupId>
             <artifactId>geronimo-admin</artifactId>
             <version>1.0</version>
             <type>car</type>
         </moduleId>

         <dependencies>

             <dependency>
                 <groupId>org.apache.geronimo.framework</groupId>
                 <artifactId>j2ee-security</artifactId>
                 <type>car</type>
             </dependency>

         </dependencies>

     </environment>

     <gbean name="geronimo-admin"
       class="org.apache.geronimo.security.realm.GenericSecurityRealm"
       xsi:type="dep:gbeanType"
      xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

         <attribute name="realmName">geronimo-admin</attribute>
         <reference name="ServerInfo">
             <name>ServerInfo</name>
         </reference>

         <xml-reference name="LoginModuleConfiguration">

             <log:login-config xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0">
                 <log:login-module control-flag="REQUIRED" wrap-principals="false">
                     <log:login-domain-name>geronimo-admin</log:login-domain-name>
                     <log:login-module-class>
  org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
                     </log:login-module-class>
                     <log:option name="groupsURI">var/security/groups.properties</log:option>
                     <log:option name="usersURI">var/security/users.properties</log:option>
                 </log:login-module>
             </log:login-config>

         </xml-reference>
     </gbean>

 </module>

The above security realm is deployed over two property files <geronimo_home>/var/security/users.properties and var/security/groups.properties that contain user/group information using org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule. The admin console is a web application that uses the above security realm for user authentication.

The security realm deployment plan is an XML file that uses http://geronimo.apache.org/xml/ns/deployment-1.2 schema for moduleid, dependency and security realm GBean configurations. The XML file uses http://geronimo.apache.org/xml/ns/loginconfig-2.0 schema for login module configuration. All the XML schema files (.xsd) are located at <geronimo_home>/schema directory.

The following table provides the summary of user/group repositories and corresponding login modules in Apache Geronimo

Depending on the type of the login module, the options for configuration changes. 

Once a security realm is deployed, it's available for any JEE5 application deployed in geronimo to map declared roles to actual users/groups through a geronimo deployment plan.

Applications

An enterprise application archive (ear) can consist of several application modules. The application modules can be several web application archives war) , EJB modules (jar), application client modules (jar) or resource archive modules (rar). User can either deploy these modules individually or bundle them into a single ear file and deploy the ear file.

When deployed individually, each application module should accompany a geronimo deployment plan to map declared resources names, ejb names, security roles, JMS roles (if any) to actual resources in the server. The geronimo deployment plans also contain any geronimo specific settings and configurations. When deployed as a single bundle (ear), user can create a single geronimo deployment plan accomplish to perform all the mappings/settings and configurations.

The following table summarizes different JEE5 modules and corresponding geronimo deployment plans accompany them.

Web Application deployment plan

In the geronimo-web.xml file, application deployer maps the security roles, ejb names, database resources, JMS resources, etc. declared in web.xml to corresponding entities deployed in the server. In addition to that, if there are any web container specific configurations, such as tomcat or jetty specific, depending on the application needs, all these settings are configured as well here. If the web application depends on any third party libraries or other services running in the server, all these dependencies are declared in the plan. Some web applications require class loading requirements different from the default class loading behavior. The geronimo-web.xml allows application deployer to configure this as well. There are many more configurations that could be done through geronimo-web.xml depending on the needs of web application. The following sections briefly explain how geronimo-web.xml can be used to configure the web container and web applications.

The geronimo-web.xml uses XML elements from http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1 namespace and one or more namespaces mentioned in Common elements and Configuration section above in the document.

For example, the following web.xml and geronimo-web.xml are the deployment descriptor and geronimo deployment plan respectively, of a web application that connects to a datasource deployed on DB2 and retrieves data from a table.

...

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                               http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
                               version="2.5">

  <resource-ref>
    <res-ref-name>jdbc/DataSource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    <res-sharing-scope>Shareable</res-sharing-scope>
  </resource-ref>

  <welcome-file-list>
    <welcome-file>jsp/EMPdemo.jsp</welcome-file>
  </welcome-file-list>
</web-app>

The web module connects to back end datasource using its JNDI name jdbc/DataSource as declared in the web.xml.

...

<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1"
          xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2"
          xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0"
          xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2">

     <sys:environment>
         <sys:moduleId>
             <sys:groupId>samples</sys:groupId>
             <sys:artifactId>EmployeeDemo</sys:artifactId>
             <sys:version>2.5</sys:version>
             <sys:type>war</sys:type>
         </sys:moduleId>
         <sys:dependencies>
             <sys:dependency>
                 <sys:groupId>samples</sys:groupId>
                 <sys:artifactId>EmployeeDatasource</sys:artifactId>
                 <sys:version>2.5</sys:version>
                 <sys:type>rar</sys:type>
             </sys:dependency>
         </sys:dependencies>
     </sys:environment>

     <context-root>/EmployeeDemo</context-root>

     <naming:resource-ref>
         <naming:ref-name>jdbc/DataSource</naming:ref-name>
         <naming:resource-link>jdbc/EmployeeDatasource</naming:resource-link>
     </naming:resource-ref>


 </web-app>

Observe the various XML tags and corresponding namespaces used in the deployment plan for various purposes.

<sys:environment> .. </sys:environment> : These elements provide the moduleid configuration and the dependencies. The moduleid elements provide the configuration name for the web module. So, when the web module is deployed, it is given the configuration name samples/samples/2.5/jar. The dependencies elements provide the configurations and third party libraries on which the web module is dependent on. These configurations and libraries will be available to the web module via a classloader hierarchy. In this case, the web module is dependent on samples/EmployeeDatasource/2.5/rar which is the configuration of the deployed Datasource that connects to a back end DB2 database. The Datasource deploys a database connection pool (javax.sql.Datasource) with name jdbc/EmployeeDatasource.

<sys:context-root> .. </sys:context-root> : The XML elements used to provide the web context root of the web applications.

<naming:resource-ref> .. </naming:resource-ref> : These elements help us to configure the resource references. In this case, the datasource reference jdbc/DataSource is mapped to jdbc/EmployeeDatasource.

In the EMPdemo.jsp, the following java code snippet is used to obtain a connection from the datasource.

...

....
....
Context initContext = new InitialContext();
Context envContext  = (Context)initContext.lookup("java:comp/env");
DataSource ds = (DataSource)envContext.lookup("jdbc/DataSource");
Connection con = ds.getConnection();
....
....

The above descriptor and the plan files are the simple illustrations that explain how web modules are developed and assembled for apache geronimo. Similarly, many other configurations can be performed in the geronimo-web.xml.

All the XML schema files are located at <geronimo_home>/schema directory. Please go through the .xsd files to have a feel of XML tags that can be used in geronimo-web.xml for configuring web applications.

EJB Application deployment plan

Geronimo uses OpenEJB container for providing ejb services. With the advent of JEE 5, the ejb container services such as transaction management, security, life cycle management can be declared in the ejb class itself using annotations. However, the ejb deployment descriptor can still be provided through ejb-jar.xml file. When both annotations and ejb-jar.xml file are provided, the ejb-jar.xml file takes precedence over the annotations.

The openejb-jar.xml file contains deployment plan for ejb modules. In the openejb-jar.xml file, the application deployer maps the security roles, ejb names, database resources, JMS resources, etc. declared in ejb-jar.xml file to corresponding entities deployed in the server. In addition to that, if there are any ejb container specific configurations to be done, the required settings are configured as well here. If the ejb module depends on any third party libraries or other services running in the server, all these third party libraries and the services are specified in the openejb-jar.xml file. Some ejb applications require class loading requirements different from the default class loading behavior. The openejb-jar.xml file allows application deployer to configure this as well. There are many more configurations that could be done through openejb-jar.xml file depending on the needs of the ejb application. The following sections briefly explain how openejb-jar.xml file can be used to configure the ejb container and ejb applications.

For example, the below XML content is the deployment descriptor (ejb-jar.xml) of a stateless session bean that connects to a back end DB2 database.

...

<?xml version="1.0" encoding="UTF-8" ?> 
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" version="3.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
  
  <description>Stateless Session Bean Example</description> 
  <display-name>Stateless Session Bean Example</display-name> 
  
 <enterprise-beans>
   <session>
     <ejb-name>RetrieveEmployeeInfoBean</ejb-name>
     <business-remote>examples.session.stateless_dd.RetrieveEmployeeInfo</business-remote>
     <ejb-class>examples.session.stateless_dd.RetrieveEmployeeInfoBean</ejb-class> 
     <session-type>Stateless</session-type> 
     <transaction-type>Container</transaction-type> 
 	  <resource-ref>
		<res-ref-name>jdbc/DataSource</res-ref-name>
		<res-type>javax.sql.DataSource</res-type>
		<res-auth>Container</res-auth>
		<res-sharing-scope>Shareable</res-sharing-scope>
	  </resource-ref>
   </session>
 </enterprise-beans>
 
 <interceptors>
   <interceptor>
       <interceptor-class>
	                   examples.session.stateless_dd.RetrieveEmployeeInfoCallbacks
       </interceptor-class>
       <post-construct><lifecycle-callback-method>construct</lifecycle-callback-method></post-construct>
       <post-activate><lifecycle-callback-method>activate</lifecycle-callback-method></post-activate>
       <pre-passivate><lifecycle-callback-method>passivate</lifecycle-callback-method></pre-passivate>
    </interceptor>
  </interceptors> 
 
  <assembly-descriptor>
    <interceptor-binding>
      <ejb-name>RetrieveEmployeeInfoBean</ejb-name>
      <interceptor-class>examples.session.stateless_dd.RetrieveEmployeeInfoCallbacks
      </interceptor-class>
    </interceptor-binding>  
  </assembly-descriptor>  
</ejb-jar>

The ejb module connects to back end datasource using its JNDI name jdbc/DataSource as declared in the ejb-jar.xml. It also declares that the ejb is a stateless session bean and provides an interceptor class for the bean. The interceptor class will have callback methods which container calls when the corresponding events occur in the bean's life cycle.

For the above deployment descriptor, we will have to provide a corresponding deployment plan file (openejb-jar.xml) that maps the declared datasource to actual datasource deployed in the server. The following is the deployment plan.

...

<openejb-jar xmlns="http://openejb.apache.org/xml/ns/openejb-jar-2.2" 
         xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2" 
         xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0" 
         xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2">

   <sys:environment>
        <sys:moduleId>
            <sys:groupId>samples</sys:groupId>
            <sys:artifactId>EmployeeDemo-ejb-dd</sys:artifactId>
            <sys:version>3.0</sys:version>
            <sys:type>jar</sys:type>
        </sys:moduleId>
    	
         <sys:dependencies>
	   <sys:dependency>
                <sys:groupId>console.dbpool</sys:groupId>
                <sys:artifactId>jdbc%2FEmployeeDatasource</sys:artifactId>
                <sys:version>1.0</sys:version>
                <sys:type>rar</sys:type>
           </sys:dependency>
	 </sys:dependencies>
    </sys:environment>
	
	<enterprise-beans>
		<session>
			<ejb-name>RetrieveEmployeeInfoBean</ejb-name>
			   <naming:resource-ref>
				 <naming:ref-name>
					jdbc/DataSource
                                 </naming:ref-name>
			         <naming:resource-link>jdbc/EmployeeDatasource</naming:resource-link>
			   </naming:resource-ref>
		</session>
	</enterprise-beans>
</openejb-jar>	

Observe the various XML tags and corresponding namespaces used in the deployment plan for various purposes.

<sys:environment> .. </sys:environment> : These elements provide the moduleid configuration and the dependencies. The moduleid elements provide the configuration name for the ejb module. So, when the ejb module is deployed, it is given the configuration name samples/EmployeeDemo-ejb-dd/3.0/jar. The dependencies elements provide the configurations and third party libraries on which the ejb module is dependent on. These configurations and libraries will be available to the ejb module via a classloader hierarchy. In this case, the ejb module is dependent on console.dbpool/jdbc%2FEmployeeDatasource/1.0/jar which is the configuration of the deployed Datasource that connects to a back end DB2 database. The Datasource deploys a database connection pool (javax.sql.Datasource) with name jdbc/EmployeeDatasource.

<enterprise-beans> .. </enterprise-beans> : These elements help us to configure the enterprise beans. In this case, the datasource reference jdbc/DataSource is mapped to jdbc/EmployeeDatasource.

In the ejb bean class, the following java code is used to obtain a connection from the datasource.

...

....
....
Context initContext = new InitialContext();
Context envContext  = (Context)initContext.lookup("java:comp/env");
DataSource ds = (DataSource)envContext.lookup("jdbc/DataSource");
Connection con = ds.getConnection();
....
....

The above descriptor and plan are the simple illustrations that explain how ejb modules are developed and assembled for apache geronimo. Similarly, many other configurations can be performed in the openejb-jar.xml. The schema for the plan is openejb-jar-2.1.xsd

Enterprise application deployment plan

An enterprise application archive (ear) can consist of many sub modules. The sub modules can be web modules (war), ejb modules (jar), resource adapter modules (rar) or application client modules (jar). When an ear consist of many sub modules, the deployment plans for all the sub modules can be provided in a single file named geronimo-application.xml. This single file contains the deployment details of each of the sub modules of the ear. Alternatively, each of the sub modules can package its corresponding deployment plan file within itself. However, the preferable way is to provide a single deployment plan through geronimo-application.xml for all the sub modules. This mechanism provides flexibility of allowing us to modify the deployment configuration for all modules through a single file. In this section, we explore ear deployment plan and understand what it contains.

An enterprise application archive (ear) should provide its deployment descriptor in application.xml. The application.xml lists all the sub modules in the ear file along with the descriptions. Along with the deployment descriptor, deployer should also provide geronimo specific deployment plan in geronimo-application.xml. Along with the description of each of the sub modules of the ear file, this file also provides mappings for JEE resources that each of the sub modules refers in their deployment descriptor. The geronimo-application.xml is divided into several sections where in each section, the deployment plan for a sub module is provided. The deployment plan borrows XML elements from all other schemas. It is the highest level plan that provides deployment plan for all sub modules; hence it can contain XML elements from every other geronimo XML schema used by geronimo application deployer. At first glance of this file, one can conclude that it embeds geronimo-web.xml, openejb-jar.xml, geronimo-ra.xml and geronimo-application-client.xml in a single XML file.

For example, following is the structure of an ear that has a web module and an ejb module.

Image Removed

The above Order.ear file contains two modules. One is OrderWEB.war file which is a web module and the other is OrderEJB.jar file which is an ejb module. The META-INF folder of Order.ear file contains the application deployment descriptor (application.xml) and the geronimo application deployment plan (geronimo-application.xml). The web application and the ejb application have packaged only their respective deployment descriptors. But the deployment plans for these modules are provided in the geronimo-application.xml.
The web application (OrderWAR.war) looks up stateless session bean in the OrderEJB.jar module to retrieve the order information. The RetrieveOrderInfoBean in OrderEJB.jar module uses JDBC connection to read the order information from a DB2 database.

The deployment descriptor of the OrderEJB.jar is as follows.

...

<?xml version="1.0" encoding="UTF-8" ?> 
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" version="3.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
             http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
  <description>Stateless Session Bean Example</description> 
  <display-name>Stateless Session Bean Example</display-name> 
 <enterprise-beans>
   <session>
     <ejb-name>RetrieveOrderInfoBean</ejb-name>
     <business-local>
         examples.session.stateless_dd.RetrieveOrderInfo
     </business-local>
     <ejb-class>
         examples.session.stateless_dd.RetrieveOrderInfoBean
     </ejb-class> 
     <session-type>Stateless</session-type> 
     <transaction-type>Container</transaction-type> 
 
	  <resource-ref>
		<res-ref-name>
                  jdbc/DB2DataSource
                </res-ref-name>
		<res-type>
                  javax.sql.DataSource
                </res-type>
		<res-auth>Container</res-auth>
		<res-sharing-scope>
                  Shareable
                </res-sharing-scope>
	  </resource-ref>
		 
	 
   </session>
 </enterprise-beans>
 
 <interceptors>
   <interceptor>
       <interceptor-class>
         examples.session.stateless_dd.RetrieveOrderCallbacks
       </interceptor-class>
       <post-construct>
         <lifecycle-callback-method>
            construct
         </lifecycle-callback-method>
       </post-construct>
       <pre-destroy>
          <lifecycle-callback-method>
              destroy
          </lifecycle-callback-method>
       </pre-destroy> 
    </interceptor>
  </interceptors> 
  
  <assembly-descriptor>
    <interceptor-binding>
      <ejb-name>RetrieveOrderInfoBean</ejb-name>
      <interceptor-class>
        examples.session.stateless_dd.RetrieveOrderCallbacks
      </interceptor-class>
    </interceptor-binding>  
  </assembly-descriptor>  
</ejb-jar>

The deployment descriptor of the OrderWEB.war is as follows.

...

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xmlns="http://java.sun.com/xml/ns/javaee" 
     xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  
     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
      http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
     id="WebApp_ID" 
     version="2.5">
  <display-name>OrderWEB</display-name>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
  <servlet>
    <description></description>
    <display-name>RetrieveOrder</display-name>
    <servlet-name>RetrieveOrder</servlet-name>
    <servlet-class>
       examples.web.servlet.RetrieveOrder
    </servlet-class>
  </servlet>
  <ejb-local-ref>
  	<ejb-ref-name>ejb/RetrieveOrderInfo
        </ejb-ref-name>
  	<ejb-ref-type>Session</ejb-ref-type>
  	<local>
         examples.session.stateless_dd.RetrieveOrderInfo
        </local>
  	<ejb-link>RetrieveOrderInfoBean</ejb-link>
  </ejb-local-ref>
  <servlet-mapping>
    <servlet-name>RetrieveOrder</servlet-name>
    <url-pattern>/RetrieveOrder</url-pattern>
  </servlet-mapping>
</web-app>

The deployment descriptor of the Order.ear is as follows.

...

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://java.sun.com/xml/ns/javaee" 
 xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
 http://java.sun.com/xml/ns/j2ee/application_5.xsd" version="5">
  <description>EAR Example</description>
  <display-name>Order Sample</display-name>
  <module>
    <web>
      <web-uri>OrderWEB.war</web-uri>
      <context-root>/OrderDemo</context-root>
    </web>
  </module>
  <module>
    <ejb>OrderEJB.jar</ejb>
  </module>
</application>

The deployment plan of the Order.ear is as follows.

...

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-2.0" 
             xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2" 
             application-name="Order">
  <sys:environment>
    <sys:moduleId>
      <sys:groupId>Order</sys:groupId>
      <sys:artifactId>OrderEAR</sys:artifactId>
      <sys:version>5.0</sys:version>
      <sys:type>car</sys:type>
    </sys:moduleId>
  </sys:environment>
  
    <module>
        <web>OrderWEB.war</web>
        <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" >
        <sys:environment>
            <sys:moduleId>
            	<sys:groupId>Order</sys:groupId>
            	<sys:artifactId>OrderWEB</sys:artifactId>
            	<sys:version>2.5</sys:version>
            	<sys:type>war</sys:type>
        	</sys:moduleId>
        </sys:environment>
 			<context-root>/OrderDemo</context-root>
        </web-app>
    </module>
    
	<module>
        <ejb>OrderEJB.jar</ejb>
        <openejb-jar 
         xmlns="http://openejb.apache.org/xml/ns/openejb-jar-2.2" 
         xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2">

   		<sys:environment>
        	 <sys:moduleId>
            	  <sys:groupId>Order</sys:groupId>
            	  <sys:artifactId>OrderEJB</sys:artifactId>
          	  <sys:version>3.0</sys:version>
            	  <sys:type>jar</sys:type>
        	</sys:moduleId>
		
         	<sys:dependencies>
		 <sys:dependency>
                  <sys:groupId>console.dbpool</sys:groupId>
                  <sys:artifactId>OrderDS</sys:artifactId>
                  <sys:version>1.0</sys:version>
               	  <sys:type>rar</sys:type>
            	 </sys:dependency>
		</sys:dependencies>
    		</sys:environment>
    		
		<enterprise-beans>
		<session>
		 <ejb-name>RetrieveOrderInfoBean</ejb-name>
	          <naming:resource-ref>
		   <naming:ref-name>
                     jdbc/DB2DataSource
                   </naming:ref-name>
		   <naming:resource-link>
                      OrderDS
                   </naming:resource-link>
		  </naming:resource-ref>
			</session>
		</enterprise-beans>
	    		
        </openejb-jar>
	</module>        
</application>

Please observe how the JEE 5 resource names and ejb names in ejb-jar.xml and web.xml are mapped to actual resources deployed in the server through geronimo-application.xml.

As we can observe from the geronimo-application.xml, the deployment plans for web and ejb modules are wrapped in <module> .... </module> elements. The xml elements used to provide deployment plan for the web module are from the schema http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1^{Image Removed} which is the schema for geronimo-web.xml. Similarly, the xml elements used to provide ejb deployment plan are from the schema http://openejb.apache.org/xml/ns/openejb-jar-2.2^{Image Removed} which is the schema for openejb-jar.xml. Hence, geronimo-application.xml barrows elements from all other schemas to provide deployment plan for its sub modules.

Also, observe that, in the geronimo-application.xml, along with moduleId configuration for ear, the moduleId configuration for both web and ejb modules are provided. If the above ear file deployed on the server and the configurations are listed, the following output is displayed on the console.

C:\Geronimo-2.1\bin>deploy.bat --user system --password manager list-modules
Using GERONIMO_BASE:   C:\Geronimo-2.1
Using GERONIMO_HOME:   C:\Geronimo-2.1
Using GERONIMO_TMPDIR: var\temp
Using JRE_HOME:        C:\sun\jre
Found 92 modules
  + Order/OrderEAR/5.0/car
      `-> OrderWEB.war
      `-> OrderEJB.jar
  + console.dbpool/OrderDS/1.0/rar
 

...