Multiple Repositories and Server Instances

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:

1. bin
2. lib
3. schema
4. var
5. repository
6. deploy (hot deployment)

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

Multiple Server Instances

A server instance is easy to create in Geronimo:

1. set the org.apache.geronimo.server.name system property to the instance name before you start the server.  Use the syntax -Dorg.apache.geronimo.server.name=foo to name your instance foo.   Add this to your GERONIMO_OPTS environment variable, or pass it on the java command-line invocation of the server.  The server's var directory will then be in <geronimo_home>/foo.  org.apache.geronimo.server.name may be any pathname relative to (descending from) <geronimo_home>.  The org.apache.geronimo.server.dir system property may also be used, and it overrides org.apache.geronimo.server.name.  Use rg.apache.geronimo.server.name to specify an absolute path, which need not be relative to <geronimo_home>.  Otherwise, the two system properties behave the same.
2. mkdir foo
3. Copy var to foo.
4. Start the server.

   Multiple Repositories

First, we consider the case 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.

1. Create a plan (say repo2.xml) for your repository module.

<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2">
 <environment>
  <moduleId>
   <groupId>org.example.configs</groupId>
    <artifactId>myrepo</artifactId>
    <version>2.0-SNAPSHOT</version>
    <type>car</type>
  </moduleId>
 <dependencies>
  <dependency>
   <groupId>org.apache.geronimo.configs</groupId>
   <artifactId>j2ee-system</artifactId>
   <version>2.0-SNAPSHOT</version>
   <type>car</type>
</dependency>
 </dependencies>
 <hidden-classes/>
 <non-overridable-classes/>
</environment>
 <\!--Repository-->
 <gbean name="Repo2" class="org.apache.geronimo.system.repository.Maven2Repository">
   <attribute name="root">repo2/</attribute>
   <reference name="ServerInfo">
    <name>ServerInfo</name>
   </reference>
 </gbean>

  <\!--Configuration Store service-->
  <gbean name="Local2" class="org.apache.geronimo.system.configuration.RepositoryConfigurationStore">
    <reference name="Repository">
     <name>Repo2</name>
    </reference>
  </gbean>
</module>

1. Create the repository's root directory. mkdir <geronimo_home>/repo2
   1. The directory is specified by the root attribute of the Maven2Repository GBean, repo2/ in the above example.  It is a path relative to the base directory <geronimo_home>.

1. 1. A resolveToServer attribute is being added to allow this path to be relative to baseServer, which is useful with multiple server instances.

1. Deploy the repository module by deploying 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:

>java deployer.jar list-targets Available Targets:

 org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2

 org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local The use of environment variables is recommended for command-line use.  For example, set REPO2= org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2. To deploy to the new repository, use: deploy --targets %REPO2% sample.war deploy list-modules also gives those long target names on each module. However, deploy list-modules %REPO2% gives the accustomed short output. The syntax to undeploy from a repo is: >java deployer.jar undeploy  "%REPO2%|geronimo/jsp-examples/1.1.1/war" If no --targets are given on the deploy command, the module is deployed to all repositories.  This certainly seems undesirable.  If you only want to put the module in one repository, be sure to use the --targets option!

Multiple Server Instances, each with its own repository(ies)

In the case of multiple server instances, the separate path may be given for the  Maven2Repository root attribute for each server.  To make this easier, a resolveToServer attribute is added 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 change. What's lacking is console support for multiple repositories, and support for hot deployment and plugins.