|Home > Documentation > Administration > Running Geronimo > Multiple Repositories|
This article applies to Geronimo 2.0 and later.
This article describes running multiple server instances from one installation instance of Geronimo, where the server instances share as much of the base Geronimo artifacts and file system space as possible. These are the geronimo directories, all sub-directories of <geronimo_home> by default:
<geronimo_home> is the directory where you installed Geronimo. bin, lib and schema are read-only, and thus may be shared between instances. The disk space taken up by a typical vanilla freshly installed Geronimo instance is equally split between var and repository at almost 50 MB each, with the rest being noise. Most of var is 40 MB of ActiveMQ journal files.This motivates the idea of a second repository, in particular, one for each server instance.
In addition to a simple read/write partition of capabilities, security may well come into play as we access permissions on a set of directories. Each server instance should be able to read or write only its var directory, for instance.
A feature that helps with running multiple servers, whether or not they are sharing a repository, is the configuration substitution property facility. config.xml can have expressions of the form
etc. These expressions are evaluated with jexl using values set from:
A server instance is easy to create in Geronimo:
org.apache.geronimo.server.namesystem property to the instance name before you start the server.
-Dorg.apache.geronimo.server.name=footo name your instance
GERONIMO_OPTSenvironment variable, or
org.apache.geronimo.server.namemay be any pathname relative to (descending from) <geronimo_home>. For example,
servers/barwould put the server's var directory under
org.apache.geronimo.server.dirsystem property may also be used, and it overrides
org.apache.geronimo.server.dirto specify an absolute path, which need not be relative to <geronimo_home>. For example,
/ag20/servers/barwould put the server's var directory under
/ag20/servers/bar. Otherwise, the two system properties behave the same.
PortOffsetand change it to a value like
1,2,10,11,12,20,21,22,...so the ports in the new server instance will not conflict with existing server instances you already have defined and/or started. (Alternatively start the server with the property -Dorg.apache.geronimo.config.substitution.PortOffset=3 in the command line)
To deploy applications to the new server instance, you need to specify the NamingPort+PortOffset used, such as for PortOffset=1:
First, we consider the single server instance case, and just add a second repository. Say we want to leave Geronimo in its repository, but add a second repository to deploy our applications. Adding a second repository is pretty easy.
rootattribute of the Maven2Repository GBean,
repo2s/in the above example. It is a path relative to the base directory <geronimo_home>.
resolveToServerattribute specifies the repository's location.
truemeans this path is relative to baseServer, which is useful with multiple server instances.
falsemeans this path is relative to the base directory <geronimo_home>.
deploy deploy repo2.xml.
Using the new repository is a little tricky, and is only supported from the command line currently. The essence is to use the
--targets option of the
deploy command to target your module to deploy in your new repository. First, use the deployer list-targets command to see the repositories. The target names are long and cumbersome:
To deploy to the new repository, use:
deploy deploy --targets %REPO2% sample.war
deploy list-modules also gives those long target names for each repo, followed by the usual short names of each module deployed in the repo.
deploy list-modules %REPO2% gives the accustomed short output for the target repo.
The syntax to undeploy from a repo is:
deploy undeploy "%REPO2%|geronimo/jsp-examples/1.1.1/war".
In the case of multiple server instances, a separate path may be given for the Maven2Repository root attribute for each server. This might be done with
config.xml overrides for each server instance. A better solution is to add a
resolveToServer attribute to this GBean, so that the
root attribute may be set to
repository, and it will thus be unique for each server instance with no changes required for each instance. Each server instance would then have a repository located at