Versions Compared

Old Version 40

changes.mady.by.user Tim McConnell

Saved on

compared with

New Version 41

changes.mady.by.user Tim McConnell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Schema top-level elements

This schema is container-independent, meaning that it can be used to deploy to Simileither of the Tomcat or Jetty web containers supported by Geronimo. If it is necessary to deploy to a specific container, one of the following schemas can be used instead. These allow container-specific configuration elements that are only understood by either the Tomcat or Jetty web container. Additionally, while the container-independent schema has no container-specific elements, it does faciliate 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 SystemThe 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:

...

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

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. 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 on the same open source project libraries. The <hidden-classes> element is typically used when the web application has requirements one 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, which 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 library included with the web application 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 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 specify a list of classes which will never be loaded from parent ClassLoaders of this module. For example, if Log4J was listed here, the module would never see Geronimo's copy of Log4J. If the module provided it's own Log4J JAR it would use that, otherwise it would not be able to load Log4J at all.
    The <non-overridable-classes> element can be used to specify a list of classes which will only be loaded from the parent ClassLoaders classloader of this module (never from the module's own ClassLoader). For example, this is used to prevent a web application from redefining "javax.servlet", so those classes will always be loaded from the server instead of from the web application's own ClassPaththe web application module to ensure that the Geronimo server's version of a libary 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 <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).

...