Page History

...

Embedded in an JAR file. In this case, a geronimo-application-client.xml file must be placed in the /META-INF directory of the JAR.
Maintained separately from the JAR file. In this case, the path to the file must be provided to the appropriate Geronimo deployer (e.g., command-line or console). Note that in this case, the filename can be named something other than geronimo-application-client.xml but must adhere to the same schema.
Embedded in an application EAR file and referenced by an <alt-dd> element of the EAR deployment plan.

...

http://geronimo.apache.org/schemas-2.1/docs/geronimo-application-client-2.0.xsd.html

...

Schema top-level elements

The top-most root XML element in the geronimo-application-client-2.0.xsd schema is the <application-client> element. The top-level XML elements of the <application-client> root element are described in the sections below. The deployment plan should always use the application client namespace, and it typically requires elements from Geronimo System, Geronimo Naming, and Geronimo Security namespaces. A typical deployment for geronimo-application-client.xml can be presented as follows:

...

Code Block

	xml
	xml
title	geronimo-web.xml Example
borderStyle	solid


<client:application-client
             xmlns:client="http://geronimo.apache.org/xml/ns/j2ee/application-client-2.0"
             xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.2"
             xmlns:name="http://geronimo.apache.org/xml/ns/naming-1.2"
             xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0">
             ...
</client:/application-client>

<sys:environment>

The <sys:client-environment> elements use XML element uses the Geronimo deployment namespace described at System namespace, which is used to specify the common elements for common libraries and module-scoped services for the client application JVM, and is described here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-module-1.2.xsd.html^{Image Modified}

. The <sys:client-environment> is used to specify the environment for the client application JVM and 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 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 or packages 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 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 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 application clients however.

<sys:server-environment>

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

http://geronimo.apache.org/schemas-2.1/docs/geronimo-module-1.2.xsd.html^{Image Modified}

. The <sys:server-environment> is used so specify the environment for the server-side support module and 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 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 allprovide 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 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 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 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 applications clients however.

Code Block

	xml
	xml
borderStyle	solid
title	<sys:client-environment> and < sys:server-environment> example

<application-client
 xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-client-2.0
 xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">

    <dep:client-environment>
        <dep:moduleId>
            <dep:groupId>JEE5</dep:groupId>
            <dep:artifactId>EXAMPLEClient</dep:artifactId>
            <dep:version>2.1</dep:version>
            <dep:type>car</dep:type>
        </dep:moduleId>
    </dep:client-environment>

    <dep:server-environment>
        <dep:moduleId>
            <dep:groupId>JEE5</dep:groupId>
	    <dep:artifactId>EXAMPLEClientServer</dep:artifactId>
	    <dep:version>2.1</dep:version>
	    <dep:type>car</dep:type>
        </dep:moduleId>
    </dep:server-environment>
    
</application-client>

...

The <naming:gbean-ref> XML element uses the Geronimo Naming namespace, which is used to identify the common elements for resolving GBean references, resource references, and Web services references, and is described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2.xsd.html^{Image Modified}

. It is used to map GBean references to GBeans in other applications using the ref-name provided in the GBean deployment descriptor.

...

The <naming:ejb-ref> 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 described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2.xsd.html^{Image Modified}

. It 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 current application.

...

The <naming:service-ref> 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 described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2.xsd.html^{Image Modified}

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

...

The <naming:resource-ref> 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 described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2.xsd.html^{Image Modified}

. It is used to map resource references to resources's like JDBC resources, JMS resources, etc. configured outside the current application.

...

The <naming:resource-env-ref> 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 described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2.xsd.html^{Image Modified}

. It is used to map resource references to administrative objects deployed as a part of connectors.

...

The <naming:message-destination> 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 described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-naming-1.2.xsd.html^{Image Modified}

. It is used to configure a JMS queue or topic which acts like a destination for the messages delivered.

...

The <sec:default-subject> element uses the Geronimo deployment namespace described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-security-2.0.xsd.html^{Image Modified}.

<realm-name>

The <realm-name> element uses the Geronimo deployment namespace described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-application-client-2.0.xsd.html^{Image Modified}

. It names the security realm used for JAAS login.

...

The <resource> element uses the Geronimo deployment namespace described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-application-client-2.0.xsd.html^{Image Modified}

. It specifies the name of a callback class provided by the application for JAAS authentication. This class must implement the javax.security.auth.callback.CallbackHandler interface and follow its specification, as this class will be used by the application client container to collect authentication information from the user.

...

The <resource> element uses the Geronimo deployment namespace described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-application-client-2.0.xsd.html^{Image Modified}

. It contains the definition of all the module-scoped connector resources. The connector resource can be both external and internal to the application client.

...

The <sys:service> element uses the Geronimo deployment namespace described at here:

http://geronimo.apache.org/schemas-2.1/docs/geronimo-module-1.2.xsd.html^{Image Modified}

. It is an empty generic element to be extended by GBean and other module types.

Child pages

Versions Compared

Old Version 6

New Version 7

Key

Schema top-level elements

<sys:environment>

<sys:server-environment>

<realm-name>