Repository Deployment Settings

Introduction

Goal

Override Repository Servlet context parameters.

Summary

The Repository Servlet is initialized using a number of context parameters defined in the CMS application's web.xml or in a deployment context descriptor at container level. Some of these parameters can be overridden at startup using system properties.

Servlet Context Parameters

Hippo Repository is started by the Hippo Repository Servlet during the servlet initialization phase. By default, the servlet is declared in the web.xml of the CMS application as follows:

  <servlet>
    <servlet-name>Repository</servlet-name>
    <servlet-class>org.hippoecm.repository.RepositoryServlet</servlet-class>
    <load-on-startup>4</load-on-startup>
  </servlet>

The servlet reads a number of parameters that determine how Hippo Repository is started. If a given parameter is not defined as a servlet initialization parameter an attempt is made to read it as a servlet context initialization parameter instead. Since containers usually allow context parameters to be overridden with a deployment context descriptor the latter configuration method is preferred.

  <context-param>
    <description>The location of the repository configuration file. Unless
                 the location starts with file://, the location is retrieved
                 from within the application package as resource.
    </description>
    <param-name>repository-config</param-name>
    <param-value>repository.xml</param-value>
  </context-param>
  <context-param>
    <description>The (relative) location where to store files</description>
    <param-name>repository-directory</param-name>
    <param-value>storage</param-value>
  </context-param>
  <context-param>
    <description>The address of the repository</description>
    <param-name>repository-address</param-name>
    <param-value>rmi://localhost:1099/hipporepository</param-value>
  </context-param>

Some of these parameter settings can be overridden by system properties as described below.

Repository Descriptor Location

The repository configuration file contains the bulk of configuration settings of a Hippo Repository instance. To specify the location of this file to use you can use the context parameter repository-config. This parameter is overridden by the system property repo.config. If the location string does not start with file: the file is loaded as a resource from the application classpath, otherwise the location string is interpreted as an absolute file path from the system root.

Repository Storage Directory Location

This is the working directory of the repository and the place where things like database files and index files are stored. To specify the location of the repository storage directory to use you can specify the context parameter repository-directory. Alternatively, you can specify the system property repo.path to override this parameter. This location property can be configured as an absolute file system path or as a path relative the application user directory. Unless you change this parameter in your development environment the repository uses a directory in the target directory of the project. This directory is removed when you run the mvn clean goal. To prevent that the repository needs to be bootstrapped every time you rebuild your project you can use this system property to specify an alternative repository storage location outside the maven target directory. 

Enable RMI

Hippo Repository can be configured to start an RMI server to allow clients to remotely access the repository via the JCR 2.0 API. To enable this feature you must set the context parameter start-remote-server to true.

Remote Address

By default the address with which the remoting service is registered is localhost:1099, but this can be configured with the context parameter repository-address.

Enable Bootstrap

When a Hippo Repository starts for the first time it does not yet contain any namespaces, nodetypes, configuration or content. Before anything else it needs to first bootstrap these. When Hippo Repository detects it has not been bootstrapped before it initiates this bootstrap process automatically on first startup. Subsequent repository startups bypass the bootstrapping process by default. If you are upgrading your project or deploying a new version this means you need to explicitly enable bootstrap processing in order to make sure the repository is updated with the latest packaged configurations. This done by setting the system property repo.bootstrap=true.