...
File | Standard Deployment Descriptors in the J2EE specification | Apache Geronimo specific Deployment plan |
|---|---|---|
Web Application Archive (WAR) | web.xml under the WEB-INF directory | geronimo-web.xml |
Enterprise Web application archive (EAR) | application.xml | geronimo-application.xml |
J2EE Connector resources archive (RAR) | ra.xml | geronimo-ra.xml |
J2EE client application archive (JAR) | client.xml | geronimo-application-client.xml |
JAR containing EJBs | ejb-jar.xml under the META-INF directory | openejb-jar.xml |
...
This is the end of the main page of the deployment plan
This is the start of the Web application deployment plans for the geronimo (sub page)
This article is organized into the following sections : -
- #Apache Geronimo v1.1 deployment plans
- #Work out Deployment Plans with Sample
- #Discussion
- #Conclusion
Work out Deployment Plans with Sample
Firstly let's work on web application deployment in Geronimo.This section is described the deployment plan structure of the web application and use of it's elements and how to implement more resource references in web applications
Assumptions
It is assumed that you have installed either Tomcat or Jetty version of Geronimo v1.1 successfully and it is working.Refer to the Installation section for further details.
Deployment plan for WAR Module
This section covers how the deployment plan works for web application module. First let's have a look at the simple "HelloWorld" example which creates a Web Application Archive (WAR) under the WEB-INF directory and has a geronimo-web.xml as the Apache Geronimo specific deployment plan.
The steps to understanding the deployment plan for the "HelloWorld" example are given below:
...
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>HelloWorld!</title>
</head>
<body bgcolor="#707DB8">
<h1>
<font face="courier" color="white">
Hello world from GERONIMO v1.1!
</font>
</h1>
<font face="courier" color="white"> ${datetime}</font>
</html>
...
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1">
<dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1">
<dep:moduleId>
<dep:groupId>geronimo</dep:groupId>
<dep:artifactId>HelloWorld</dep:artifactId>
<dep:version>1.1</dep:version>
<dep:type>war</dep:type>
</dep:moduleId>
</dep:environment>
<context-root>/hello</context-root>
</web-app>
...
<?xml version="1.0" encoding="UTF-8"?>
<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">
<welcome-file-list>
<welcome-file>HelloWorld.jsp</welcome-file>
</welcome-file-list>
</web-app>
Describing the geronimo_web deployment plan
The deployment plan should always use the Geronimo web namespace, and it typically requires elements from the Geronimo Naming namespace. Additionally, it has a required attribute to identify its configuration name, and an optional attribute to select a parent configuration. A typical web application deployment plan will includes following attributes and should be placed in WEB-INF folder
geronimo-web.xml
| Code Block |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"
xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1">
...
</web-app>
|
Describing the content of the above code :
...
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"
xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1">
... </web-app>
...
<dep:environment
xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1">
<dep:moduleId> <dep:groupId>geronimo</dep:groupId>
<dep:artifactId>HelloWorld</dep:artifactId>
<dep:version>1.1</dep:version> <dep:type>war</dep:type> </dep:moduleId>
</dep:environment>
Once you deploy the application the HelloWorld.war application will be created in <geronimo_home>/deploy/ directory
<context-root>/hello</context-root>
To access the deployed sample it's required to access the following url. This url means the context root value to access the application.
Web Application Deployment Plan Overview
There is an specific internal structure of the web application deployment plan for Geronimo as well.The web application Deployment Plans follows a specific structure and order of elements.
Web Application Identity and Class Path
The Deploy tool and the console refers the web application by the name of the name defined in the moduleID and the elements of the deployment plan configure its class path.
...
The elements here are:
ModuleId : A moduleID uniquely indentifies a specific module,including it's name ,version,etc.In fact,there are four components of a module ID.The moduleId creates a unique name for the web application. If no module ID is provided, the web application's name will be default/war-name/timestamp/war.
Dependencies : A list of dependencies for the module. Each dependency may be another module (such as an EJB module or database pool), or a third-party library located in the Geronimo repository dependency.
Holds the identifying information for a single dependency. Only the artifactId is required, but the dependency as a whole should be specific enough to identify a single JAR or module – you cannot leave out elements as a way of creating a wildcard name that matches multiple JARs.
GroupID: A Name identifying a group of related modules.This may be a project name,a company name.etc.The important thing is that each artifact ID should be unique with in the group.If no group is specified
when declaring the module ID for a module or application,it will get the group ID defualt.If no group is specified for a moduleID used to identify a dependency,then it is treated as a wildcard and the group is not used to help identify the exact dependency.
ArtifactID: A name identifying the specific module within the group.For example,there may be one group ID for an application,with separate artifact IDs for the web application and EJB modules that make up that application.Every module ID must include an explicit artifact ID.If no module ID is specified when deploying a module,the artifact ID details the files name of the module file.
Version : Each module has a version number.If the version number is specified when decaring the module ID for a module or application,it will get the numeric timestamp as it's version number.Each time the
module is redeployed it will get a new timestamp.If no version number is specified for a module ID used to identify a dependency,then any available version will be used.If there multiple versions, Geronimo favors any version that might already be loaded, or else typically the newest version will be used.
Type : A module's type is normally either car (for a system module)or the file extension for an application module (ear,war,jar,etc)If no type is specified ,the type will be set appropriately by the deployer when the module is deployed.
Import : Used for dependencies. For a dependency that's a JAR, this is not useful and should just be omitted. For a dependency that's a separate Geronimo module, there are three possibilities. One is that the class loader for the module should be added as a parent of the class loader for the web application (this might be used if the module is just an aggregation of common JARs). For that behavior, set this value to classes. The second option is that the services defined in the module should be started before and available to this module (this might be used for a database pool where the classes are not needed but the pool must be started). For that behavior, set this value to services. If this element is not included, you get both (the module is on the class path and the services are started first). Under most circumstances this element should be omitted and the default behavior will be correct.
Hidden-classes : Lists packages or classes that may be in a parent class loader, but should not be exposed from there to the web application. This is typically used when the web application wants to use a different version of a library than that of it's parent configuration (or Geronimo itself) uses.
Non-overridable-classes : Lists packages or classes that the web application should always load from a parent class loader, and never load from WEB-INF/lib or WEB-INF/classes. This might be used to force a web application to share the same instance of a common library with other web applications, even if they each include it in their own WAR.
filter classes or packages : The format is a list of packages seperated by commas or fully-qualified class names (for example: javax.servlet,javax.ejb).
inverse-classloading : Normally (if this element is omitted), the module's class loader will work normally – classes will be loaded from the parent class loader if available before checking the current class loader. If this element is added, that behavior is reversed and the current class loader will always be checked first before looking in the parent class loader. This is often enabled to give the JARs in WEB-INF/lib precedence over anything that might be in a parent class loader. This element does not take any content, it is simply present or absent.
Suppress-default-environment : This should not be used for web applications.
...
This element controls the URL that clients use to access the web application.
Context-root : The context root is the first segment of the URL used to access the web application by the client. For example, if the context-root was hello then a typical URL to the application would start with http://host:port/hello/
and a context-root value of / would be used to make this the default web application for the server.
Resolving References in Geronimo-web
The web.xml file may declare several types of references:
- GBean references
- EJB references
- Web services references
- Resource references
- Message destination references
This section describes how the geronimo-web.xml file maps those references to specific items available in the server environment.When mapping references, the target reference must be in the same application, or in a module listed as a dependency of the current application. If a resource in a different module cannot be found, the first thing to do is make sure that module is listed as a dependency
Common Resource Mapping Elements
All of the resource types use common elements to refer to other resources running in the server. These elements are grouped together under a pattern element.
...
Common References nts to a resource located elsewhere in the server. Normally only the name is required, and between the name and the type of the reference, that's enough to identify the target. The groupId, artifactId, and version can be used to identify the module that holds the target resource, in case there is more than one matching resource in the dependencies of the current module.
name : The name of the target resource (EJB, database pool, JMS connection manager, JMS destination, GBean, etc.). The element that contains the pattern identifies the type of the resource, and the type and name specified here are usually enough to uniquely identify a resource. If that's the case, none of the other elements are required. If there's a name collision, the other elements can be used to narrow it down to a single individual resource.
groupId : Identifies the group component of the Module ID of the module that the target resource is in. This should be used if more than one dependency of the web application contains a resource with the target name and type.
artifactId : Identifies the artifact component of the Module ID of the module that the target resource is in. This should be used if more than one dependency of the web application contains a resource with the target name and type.
version : Identifies the version component of the Module ID of the module that the target resource is in. This should be used if more than one dependency of the web application contains a resource with the target name and type of the module.
...
This section has to be moved in to seperate page
...