...

The Geronimo-specific deployment plan for a Web application, which is usually packaged as a WAR file, is called "geronimo-web.xml". The geronimo-web.xml deployment plan is used to in conjunction with the web.xml JAVA EE deplopyment deployment plan to deploy web applications consisting of Java Servlet Pages (JSP) and servlets to the Geronimo application server, and optionally can be used to configure the Geronimo web server (i.e., Tomcat or Jetty) where the Web application is going to be deployed. The geronimo-web.xml deployment plan is an optional file, but is typically used when deploying a WAR file. It is used to specify the application 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 requirements of web application.

...

Finally, while the generic schema has no container-specific elements, it does faciliate facilitate the inclusion of container-specific elements by using the <container-config> element. This element is described in more detail below.

...

• The <moduleId> element is used to provide the configuration name for the web application as deployed in the Geronimo server. It contains elements for the groupId, artifactId, version and module type. Module IDs are normally printed with slashes between the four components, such as GroupID/ArtifactID/Version/Type.
  
  
• The <dependencies> element is used to provide the configurations and third party libraries on which the web module is dependent upon. These configurations and libraries are made available to the web module via the Geronimo classloader hierarchy.
  
  
• The <hidden-classes> element can be used to provide some degree of control of the Geronimo classloader hierarchy, and mitigate clashes between classes loaded by the server and classes loaded by the web application. It is used to lists packages or classes that may be in a parent classloader, but must not be exposed to the web application. Since Geronimo is entirely open-source and utilizes many other open-source libraries it is possible that the server itself and the web application may have different requirements and/or priorities for the same open source project libraries. The <hidden-classes> element is typically used when the web application has requirements for a specific version of a library that is different than the version used by Geronimo itself. A simple example of this is when a web application uses, and most importantly includes, a version of the Log4J common logging library that is different than the version used by the Geronimo server itself. This might not provide the desired results. Thus, the <hidden-classes> element can be used to "hide" the Log4J classes loaded by all the parent classloaders of the web application module, including those loaded by and for the Geronimo server itself, and only the Log4J classes included with the web application library will get loaded.
  
  
• The <non-overridable-classes> element can also be used to provide some degree of control of the Geronimo classloader hierarchy, but in the exact opposite manner than provided by the <hidden-classes> element. This element can be used to specify a list of classes or packages which will only be loaded from the parent classloader of the web application module to ensure that the Geronimo server's version of a libary library is used instead of the version included with the web application.
  
  
• The <inverse-classloading> element can be used to specify that standard classloader delegation is to be reversed for this module. The Geronimo classloader delegation follows the Java EE 5 specifications, and the normal behavior is to load classes from a parent classloader (if available) before checking the current classloader. When the <inverse-classloading> element is used, this behavior is reversed and the current classloader will always be checked before looking in the parent classloader(s). This element is similar to the <hidden-classes> element since the desired behavior is to give the libraries packaged with the web application (i.e., in WEB-INF/lib) precedence over anything used by the Geroimo Geronimo server itself.
  
  
• The <suppress-default-environment> element can be used to suppress inheritance of environment by module (i.e., any default environment built by a Geronimo builder when deploying the plan will be suppressed). If the <suppress-default-environment> element is specified then any default environment build by a builder when deploying the plan will be suppressed. An example of where this is useful is when deploying a connector on an app client in a separate (standalone) module (not as part of a client plan). The connector builder defaultEnvironment includes some server modules that won't work on an app client, so you need to suppress the default environment and supply a complete environment including all parents for a non-app-client module you want to run on an app client. This element should not be used for web applications however.

...

Apache Geronimo uses OpenJPA for providing Java Persistence API to Java EE applications deployed in the server. The persistence deployment descriptor information is typically provided using a persistence.xml file. The <ee:persistence> top-level element can be used imbed the persistence deployment descriptor in the geronimo-web.xml file. More information and details about the JPA deployment descriptor can be found here: Java Persistence API deployment plans.

<sys:gbean>

The <sys:gbean> XML element uses the Geronimo System namespace, and is documented here:

...

The <naming:resource-ref> element is used to map resource references to resources 's like JDBC resources, JMS resources, etc. configured outside the current application.

...

The <naming:message-destination> element is used to configure map resource references to a message-destination which is used within the deployed web application. These are typically a JMS queue or topic which acts like a destination for the messages delivered.

Samples

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 applicationsLike all the JNDI references in this section, this element will not cause the creation of a message-destination, references an existing message-destination used within the deployed web application.