Home > Documentation > Creating deployment plans > Understanding deployment plans > geronimo-web.xml
Apache Geronimo v2.2
geronimo-web.xml
Edit Page   Browse Space   Add Page   Add News
{scrollbar}

Overview

INLINE

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 deployment descriptor 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.

Packaging

The geronimo-web.xml Geronimo-specific deployment plan can be packaged as follows:

  1. Embedded in a WAR file. In this case, the geronimo-web.xml file must be placed in the /WEB-INF directory of the WAR, which is the same place where the web.xml file must be located.

  2. Maintained separately from the WAR file: In this case, the path to the file must be provided to the appropriate Geronimo deployer (e.g., command-line or console) when the WAR file is deployed. Note that in this case, the filename may be named something other than geronimo-web.xml but must adhere to the same schema. Also note that this will not work if the EJB JAR file is to be embedded in an enterprise application EAR file (see below).

  3. Embedded in an enterprise application EAR file: In one case, the root-level element <web-app> of the geronimo-web-2.0.1.xsd schema can be embedded outside the WAR file in the EAR file's geronimo-application.xml file.

  4. Embedded in an enterprise application EAR file: In another case, the actual geronimo-web.xml file can be placed in the /META-INF directory of the EAR, which is the same location as the application.xml file.

Schema

The geronimo-web.xml deployment plan is defined by the geronimo-web-2.0.1.xsd schema located in the <geronimo_home>/schema/ subdirectory of the main Geronimo installation directory. The geronimo-web-2.0.1.xsd schema is documented here:

This schema is not container-specific, meaning that it can be used to deploy a web application to either of the Tomcat or Jetty web containers supported by Geronimo. If it is necessary to deploy to a specific container, one of the two following container-specific schemas can be used instead. These allow container-specific configuration elements that are only understood by either the Tomcat or Jetty web container.

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

Schema top-level elements

The root XML element in the geronimo-web-2.0.1.xsd schema is the <web-app> element. The top-level XML elements of the <web-app> root element are described in the sections below. The deployment plan should always use the Web application namespace, and it typically requires elements from Geronimo System, Geronimo Naming, Geronimo Security, Geronimo Application, and Geronimo Persistence namespaces. Additionally, it has a required attribute to identify its configuration name, and an optional attribute to select a parent configuration. A typical deployment for geronimo-web.xml can be presented as follows:

xmlgeronimo-web.xml Examplesolid <web:web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2" xmlns:name="http://geronimo.apache.org/xml/ns/naming-1.2" xmlns:app="http://geronimo.apache.org/xml/ns/j2ee/application-2.0" xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0" xmlns:pers="http://java.sun.com/xml/ns/persistence"> ... </web:web-app>

<sys:environment>

The <sys:environment> XML element uses the Geronimo System namespace, which is used to specify the common elements for common libraries and module-scoped services, and is documented here:

The <sys:environment> element contains the following elements:

  • 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 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 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.

An example geronimo-web.xml file is shown below using the <sys:environment> element:

xmlsolid<sys:environment> Example <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2"> <sys:environment> <sys:moduleId> <sys:groupId>default</sys:groupId> <sys:artifactId>geronimo-web-6</sys:artifactId> <sys:version>1.0</sys:version> <sys:type>car</sys:type> </sys:moduleId> <sys:dependencies> <sys:dependency> <sys:groupId>org.apache.geronimo.configs</sys:groupId> <sys:artifactId>tomcat6</sys:artifactId> <sys:version>2.1.1</sys:version> <sys:type>car</sys:type> </sys:dependency> <sys:dependency> <sys:groupId>default</sys:groupId> <sys:artifactId>geronimo-web-5</sys:artifactId> <sys:version>1.0</sys:version> <sys:type>car</sys:type> </sys:dependency> </sys:dependencies> <sys:hidden-classes/> <sys:non-overridable-classes/> <sys:inverse-classloading/> <sys:suppress-default-environment/> </sys:environment> </web-app>

<context-root>

The <context-root> XML element uses the Geronimo default namespace for the geronimo-web.xml file, and is documented here:

This element can be used to provide the web context path of the deployed web application, which appears in the URL used to address the application on a Geronimo server. As an example, if the context root is specified as <context-root>web-app-test</context-root> then the URL to the application would look like http://host:8080/web-app-test/. If the context root is specified as <context-root>/</context-root> that would become the default web application for the server. The <context-root> element is optional, but if it is not specified the context root of the web application will default to the WAR name (without the extension). If the web application is packaged in an EAR, then the context root can be specified
in the EAR's application.xml deployment descriptor.

<work-dir>

The <work-dir> XML element uses the Geronimo default namespace for the geronimo-web.xml file, and is documented here:

This element can be used to provide the work directory that will be used by this web application. For Jetty this will be relative to jetty home which is var/jetty by default, and for Tomcat this will be relative to catalina.home.

<naming:web-container>

The <naming:web-container> XML element uses the Geronimo Naming namespace, which is used to identify the common elements for resolving EJB references, resource references, and Web services references, and is documented here:

This element is used to specify a reference to a web-container specific GBean either via a pattern to the moduleId of the configuration, or via a link to a GBean. As an example, consider the case where it is required to run a web application in a Tomcat container using a dedicated port such that no other web application is allowed to use that port. To accomplish this a separate GBean would have to be defined for the "Container", "Engine", "Host", and "Connector", and a <naming:web-container> element would have to be used to reference this new Tomcat container. An example geronimo-web.xml file is shown below:

xmlsolid<naming:web-container> Example <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:sys="http://geronimo.apache.org/xml/ns/deployment-1.2"> <sys:environment> <sys:moduleId> <sys:groupId>default</sys:groupId> <sys:artifactId>geronimo-web-6</sys:artifactId> <sys:version>1.0</sys:version> <sys:type>car</sys:type> </sys:moduleId> <sys:dependencies/> <sys:hidden-classes/> <sys:non-overridable-classes/> <sys:inverse-classloading/> <sys:suppress-default-environment/> </sys:environment> <context-root>contextroot</web:context-root> <work-dir>workdir</web:work-dir> <naming:web-container> <naming:gbean-link>TomcatWebAppContainer</naming:gbean-link> </naming:web-container> <gbean name="TomcatWebAppContainer" class="org.apache.geronimo.tomcat.TomcatContainer"> <attribute name="catalinaHome">var/catalina</attribute> <reference name="EngineGBean"> <name>TomcatEngine1</name> </reference> <reference name="ServerInfo"> <name>ServerInfo</name> </reference> <reference name="WebManager"> <name>TomcatWebManager</name> </reference> </gbean> <gbean name="TomcatWebAppEngine" class="org.apache.geronimo.tomcat.EngineGBean"> <attribute name="className">org.apache.geronimo.tomcat.TomcatEngine</attribute> <attribute name="initParams"> name=WASCE </attribute> <reference name="DefaultHost"> <name>TomcatHost1</name> </reference> <references name="Hosts"> <pattern> <name>TomcatHost</name> </pattern> </references> <reference name="RealmGBean"> <name>TomcatJAASRealm</name> </reference> <reference name="TomcatValveChain"> <name>FirstValve</name> </reference> <reference name="LifecycleListenerChain"> <name>FirstListener</name> </reference> </gbean> <gbean name="TomcatWebAppHost" class="org.apache.geronimo.tomcat.HostGBean"> <attribute name="className">org.apache.catalina.core.StandardHost</attribute> <attribute name="initParams"> name=localhost appBase= workDir=work </attribute> </gbean> <gbean name="TomcatWebAppConnector" class="org.apache.geronimo.tomcat.ConnectorGBean"> <attribute name="name">HTTP</attribute> <attribute name="host">localhost</attribute> <attribute name="port">8081</attribute> <!-- Use port 8081 instead of the default of 8080 --> <attribute name="maxHttpHeaderSizeBytes">8192</attribute> <attribute name="maxThreads">150</attribute> <attribute name="minSpareThreads">25</attribute> <attribute name="maxSpareThreads">75</attribute> <attribute name="hostLookupEnabled">false</attribute> <attribute name="redirectPort">8453</attribute> <attribute name="acceptQueueSize">100</attribute> <attribute name="connectionTimeoutMillis">20000</attribute> <attribute name="uploadTimeoutEnabled">false</attribute> <reference name="TomcatContainer"> <name>TomcatWebAppContainer</name> </reference> </gbean> </web-app>

<container-config>

As previously mentioned, there are actually three schemas that can be used for the geronimo-web.xml file. The first is container-independent and can be used to deploy a web application to either of the web containers supported by Geronimo. The second two are container-dependent that contain elements specific to either the Tomcat or Jetty web container:

  1. http://geronimo.apache.org/schemas-2.1/docs/geronimo-web-2.0.1.xsd.html
  2. http://geronimo.apache.org/schemas-2.1/docs/geronimo-tomcat-2.0.1.xsd.html
  3. http://geronimo.apache.org/schemas-2.1/docs/geronimo-jetty-2.0.2.xsd.html

Which to use is left to the discretion of the user. If a web application is meant to be deployed to both Tomcat and Jetty, then the generic schema is typically used, and if a web application is meant to be deployed to only Tomcat or Jetty, then one of the container-specific schemas is typically used. However, another option is available since the generic schema allows the inclusion of the container-specific elements found in the container-specific schemas by using the <container-config> element. This allows the user to use the generic schema even when the web application requires container-specific configuration for Tomcat or Jetty (or both). An example geronimo-web.xml file is shown below using the <container-config> element to configure the Tomcat web container. Note that the <host>, <valve-chain>, and <tomcat-realm> elements are understood only by the Tomcat container, not Jetty:

xmlsolid<container-config> Example <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2"> <sys:environment> <sys:moduleId> <sys:groupId>default</sys:groupId> <sys:artifactId>geronimo-web-6</sys:artifactId> <sys:version>1.0</sys:version> <sys:type>car</sys:type> </sys:moduleId> </sys:environment> <container-config> <tomcat xmlns="http://geronimo.apache.org/xml/ns/web/tomcat/config-1.0"> <host>testhost.com</host> <valve-chain>FirstValve</valve-chain> <tomcat-realm>TomcatRealm</tomcat-realm> </tomcat> </container-config> </web-app>

<sys:gbean>

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

The <sys:gbean> element is used to define GBean(s) that are configured and deployed with the web application module. These additional Geronimo services will be deployed when the application is deployed (and stopped when the application is stopped). Normally, the implementation classes for these services are included at the server level and referenced using a dependency element.

<ee:persistence>

The <ee:persistence> XML element uses the Java EE Persistence namespace, and is documented here:

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 include the persistence deployment descriptor in the geronimo-web.xml file. More information and details about the JPA deployment descriptor can be found here: Creating deployment plans for Java Persistence API.

Security

Additional information and details for configuring security for Geronimo can be found here:

<security-realm-name>

The <security-realm-name> XML element uses the Geronimo default namespace for the geronimo-web.xml file, and is documented here:

The <security-realm-name> element is used to specify the name of the security realm that will be used for user authentication for the web application. It is used in conjunction with the <security-constraint> element in the corresponding web.xml deployment plan for this web application. This element will not cause the creation of a new security realm in Geronimo, it references a security realm that has already been created and configured. See Administering Security for details on how this is typically accomplished from the Geronimo Admin Console.

<sec:security>

The <sec:security> XML element uses the Geronimo Security namespace, and is documented here:

The <sec:security> element groups the security role mapping settings for the web application. This is an optional element, but if it is present all the web modules must make the appropriate access checks as outlined in the JACC specification. This element includes the <role-mapping> section that references the role(s) defined in the <security-role> element in the web.xml file. An example web.xml and corresponding geronimo-web.xml file is shown below with the "admin" role name defined in the web.xml is referenced in the geronimo-web.xml:

xmlsolid<security> web.xml Example <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name>Geronimo Remote Deployer</display-name> <description> Receives file upload requests from the deployer when running on a different machine than the Geronimo server. </description> <servlet> <display-name>File Upload</display-name> <servlet-name>file-upload</servlet-name> <servlet-class>org.apache.geronimo.deployment.remote.FileUploadServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>file-upload</servlet-name> <url-pattern>/upload</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Upload Servlet</web-resource-name> <url-pattern>/upload</url-pattern> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Geronimo File Upload</realm-name> </login-config> <security-role> <role-name>admin</role-name> </security-role> </web-app> xmlsolid<security> geronimo-web.xml Example <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0" xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0" xmlns:cfg="http://geronimo.apache.org/xml/ns/deployment-1.2"> <dep:environment> <dep:moduleId> <dep:groupId>org.apache.geronimo.plugins</dep:groupId> <dep:artifactId>geronimo-remote-deploy</dep:artifactId> <dep:version>2.1.1</dep:version> </dep:moduleId> <dep:dependencies/> <dep:hidden-classes/> <dep:non-overridable-classes/> </dep:environment> <context-root>/remote-deploy</context-root> <security-realm-name>geronimo-admin</security-realm-name> <sec:security> <sec:role-mappings> <sec:role role-name="admin"> <sec:principal class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="admin" designated-run-as="true"/> </sec:role> </sec:role-mappings> </sec:security> </web-app>

JNDI Environment References

All the JNDI reference elements in this section use the Geronimo Naming namespace, which is used to identify the common elements for resolving EJB references, resource references, and Web services references, and is documented here:

Additionally, more information and details about JNDI references can be found here: Global JNDI.

<naming:abstract-naming-entry>

The <abstract-naming-entry> element is not technically a JNDI reference element. It is included in this section because it is an abstract element used for containing these JNDI reference types:

  • <gbean-ref>

    The <gbean-ref> element is used to map GBean references to GBeans configured outside the current module

  • <persistenceunit-ref>

    The <persistenceunit-ref> element is used to map persistence unit references to persistence units configured outside the current module

  • <persistencecontext-ref>

    The <persistencecontext-ref> element is used to map persistence context references to persistence contexts configured outside the current module

An example geronimo-web.xml file is shown below using the <abstract-naming-entry> element to reference a persistence unit:

xmlsolid<abstract-naming-entry> Example <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2" xmlns:naming="http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2"> <sys:environment> <sys:moduleId> <sys:groupId>default</sys:groupId> <sys:artifactId>geronimo-web-6</sys:artifactId> <sys:version>1.0</sys:version> <sys:type>car</sys:type> </sys:moduleId> </sys:environment> <naming:abstract-naming-entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="naming:persistence-unit-refType"> <naming:persistence-unit-ref-name>messagedrivenbean-persistenceunitref-unitrefname</naming:persistence-unit-ref-name> <naming:persistence-unit-name>messagedrivenbean-persistenceunitref-unitname</naming:persistence-unit-name> <naming:pattern> <naming:groupId>messagedrivenbean-persistenceunitref-pattern-groupid</naming:groupId> <naming:artifactId>messagedrivenbean-persistenceunitref-pattern-artifactid</naming:artifactId> <naming:version>messagedrivenbean-persistenceunitref-pattern-version</naming:version> <naming:module>messagedrivenbean-persistenceunitref-pattern-module</naming:module> <naming:name>messagedrivenbean-persistenceunitref-pattern-name</naming:name> </naming:pattern> </naming:abstract-naming-entry> </web-app>

<naming:ejb-ref>

The <naming:ejb-ref> element is used to map EJB references to EJB's in other applications using remote home and remote interface. The application which contains the EJB being referenced should either be in same EAR or should be included in dependency list of this application. Also note as the EJB's referenced are in a different JVM all the client interfaces should also be included in the current application.

<naming:ejb-local-ref>

The <naming:ejb-local-ref> element is used to map EJB references to EJB's in other applications using local home and local interface. The application which contains the EJB being referenced should either be in same EAR or should be included in dependency list of this application. Also note as the EJB's referenced are in a different JVM all the client interfaces should also be included in the current application.

<naming:service-ref>

The <naming:service-ref> is used to map service references to service's in other applications. The application which contains the EJB being referenced should either be in same EAR or should be included in dependency list of this application.

<naming:resource-ref>

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

<naming:resource-env-ref>

The <naming:resource-env-ref> element is used to map resource references to administrative objects deployed as a part of connectors.

<naming:message-destination>

The <naming:message-destination> element is used to 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. Like 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.

   Delicious Bookmark this on Delicious    Digg! Digg this    Privacy Policy  -   Copyright © 2003-2011, The Apache Software Foundation, Licensed under ASL 2.0.