| Chapter 4. Elements of Geronimo [DRAFT (1.1)] | ||
|---|---|---|
 | Part I. Getting Started |  |
| Chapter 4. Elements of Geronimo [DRAFT (1.1)] | ||
|---|---|---|
| | Part I. Getting Started | |
Table of Contents
This chapter gives a brief introduction to many important aspects of Geronimo:
The high-level architecture of Geronimo, composed of a kernel and services
Module IDs, used to identify Geronimo modules and common libraries
How to start specific services or applications
The style and typical syntax of Geronimo configuration files
How Geronimo services, applications, and resources are packaged and deployed
The ClassLoader hierarchy used by Geronimo
These topics are more related than you might think. Every service, resource, or application is configured with a Geronimo deployment plan and deployed to the server in the same way, becoming a "module" available to the server. The kernel manages the lifecycle of the module, and the components within the module (known as GBeans). Each module can be started when the server is started, and gets its own ClassLoader when run. These ClassLoaders can be arranged into a hierarchy or graph, so each module may have many parents and many children.
At a high level, Geronimo is composed of a lightweight core (or kernel) and many modules. Each module may include system code (such as a thread pool or web container) or may be an application (such as the management console or a user-deployed application). There are several advantages to this structure:
All modules in Geronimo, whether system modules or application modules, can be individually started or stopped
It's possible to disable or remove the modules for features you don't need (perhaps CORBA or the EJB container)
It's possible to add new features to Geronimo by installing additional modules
It's easy to distribute modules to other servers or users in the form of Geronimo Plugins
One of the side effects of this structure is that every module has a Module ID, and you will become very used to seeing module IDs when dealing with Geronimo.
A module ID uniquely identifies a specific module, including its name, version, etc. In fact, there are four components of a module ID:
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 within the group. If no group is specified when declaring the module ID for a module or application, it will get the group ID default. If no group is specified for a module ID used to identify a dependency, it's treated as a wildcard and the group is not used to help identify the exact dependency.
A name identifying the specific module within the group. For example, there may be a single 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 at all is specified when deploying a module, the artifact ID defaults to the files name of the module file.
Each module has a version number, normally in a format like
1.2.3. If no version number is specified when declaring the module
ID for a module or application, it will get a numeric timestamp as
its version number (e.g.
System.currentTimeMillis()). 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,
it means that any available version will be used. If there are
multiple versions, Geronimo favors any version that might already
be loaded, or else typically the newest version will be
used.
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.
Module IDs are normally printed with slashes between the four components, such as GroupID/ArtifactID/Version/Type. A module ID with all 4 components is known as fully resolved. Any module that has been deployed will have a fully resolved module ID. However, you may use unresolved module IDs when declaring dependencies on other modules -- normally omitting the version number to indicate that any version will suffice.
Module IDs are also used to refer to common libraries included with Geronimo, and available for use by system modules or applications. These common libraries are typically JARs, but use the same identifier format of GroupID/ArtifactID/Version/Type.
This makes it simple for a system module or application to declare its dependencies. The syntax is the same no matter whether the dependency is a shared library (JAR) or another module (for example, a web application WAR might depend on a database pool module, which as we'll discuss in Section 4.4.3, “Deploying JDBC and JMS Resources”, is configured as a RAR).
Example 4.1. Module IDs and Dependencies
Module IDs and dependencies are defined in the <environment> block of an XML file. Any application or module can declare a module ID for itself using the moduleId element, and can declare dependencies using the dependency element. For example:
<environment>
<moduleId>
<groupId>samples</groupId>
<artifactId>test-web-app</artifactId>
</moduleId>
<dependencies>
<dependency>
<artifactId>SampleDBPool</artifactId>
<type>rar</type>
</dependency>
<dependency>
<groupId>samples</groupId>
<artifactId>test-ejbs</artifactId>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.8</version>
<type>jar</type>
</dependency>
</dependencies>
</environment>The module ID for this web application will become something
like samples/test-web-app/1147815453340/war,
depending on the exact time it was deployed (since the default for
creating a module if no version is specified is to use a
timestamp).
The web application itself depends on a RAR module with the name
SampleDBPool (probably a database connection pool),
and a module whose group is samples and name is
test-ejbs (probably an EJB module with a module ID
something like samples/test-ejbs/1.2/jar). Finally,
it depends on Log4J 1.2.8, which is a common library included with
Geronimo. The classes from all of those will be included in the web
application's class loader, and the database pool and EJBs will always
be started (if they're not already running) when this web application
is started.
Geronimo includes a repository that holds modules and third-party
JARs. The repository is located in repository/ under the Geronimo installation
directory, and has a strict internal structure, modeled after the module
ID for the contents. So, given a module ID of
group/artifact/version/type, the content for that
module in the repository will be located at
repository/.
It's possible to manually add files to the repository, so long as you
follow this structure exactly (for instance, every JAR file must have a
version number in the path and also the file name). However, it's
easiest to add files to the repository using the administration console,
where the mechanics of the file paths will be handled for you.group/artifact/version/artifact-version.type
Example 4.2. Files in the Repository
The web application from the last example might have the module
ID samples/test-web-app/1147815453340/war, and it
depended on a Log4J with the module ID
log4j/log4j/1.2.8/jar. These can be found in the
repository at:
samples/test-web-app/1147815453340/test-web-app-1147815453340.war log4j/log4j/1.2.8/log4j-1.2.8.jar
![[Note]](images/note.png) | Note |
|---|---|
Many entries in the repository are JAR files (regardless of the actual file extension). However, any entries for modules will actually be unpacked archives -- directories laid out like the original archive was packaged. Even if a module is deployed as e.g. a WAR file or EAR file, it will be unpacked when it is installed into the repository. |
| |  | |
| 3.6. Running Geronimo as a Windows or UNIX Service |  | 4.2. The Kernel and GBeans |