Configuration

As we discussed in the Extension Points section, ECR is mainly configured using XML contribution to the extension points defined in the application.

Also you can provide a set of Java .properties to initialize the variables used by ECR services or used inside XML extensions for parametrization.

ECR is uses several directories to store logs, configuration or temporary data. These directories are:

1. The home or working directory of ECR. Here ECR stores several informations as we will see later.
2. The log` directory where logs are stored.
3. The data directory where persistent data (like the repository content, etc.) is stored.

The locations of these directories can be configured through system properties.

Here is the list of the system properties you can use to configure the ECR application:

1. ecr.home.dir - to configure the location of the home directory.

   Default value: ${user.home}/.ecr

2. ecr.log.dir - to configure the location of the log directory.

   Default value: ${ecr.home.dir}/log

3. ecr.data.dir - to configure the location of the data directory.

   Default value: ${ecr.home.dir}/data

4. ecr.app.id - to set the ID of the application - not yet used but may be used in future in cloud deployment.

   Default value: default

5. ecr.database - the database identifier to use for the repository. Currently you can use either h2 either psql as values.

   Default value: h2

6. ecr.config.provider - to set a custom configuration provider.

   Default value: org.eclipse.ecr.application.internal.ConfigurationProvider

7. ecr.config.uri - the uri to be used by the configuration provider for the configuration. The value is dependent on the configuration provider.

   Default value: ${ecr.home.dir}/config

8. ecr.app.config - points to a file path or URL for a .properties file to be used to configure the above properties.

The Configuration Provider

The configuration provider is used by ECR to get the list of global configuration files. The provider class must implement Iterable<URL> and should return at demand an URL iterator over all global configuration files (these files are usually XML extensions and Java .properties files to setup the application properties)

ECR use a configuration provider instead if a directory containing the configuration file to be able to store the configuration anywhere you like - for example in a database or in a shared locations on the net. This is useful in cloud deployments to be able to manage the configuration using a central service.

To configure existing services, you may declare new extensions that will be contributed to the existing extension point registries. If you want to let other bundles configure your own services, you can declare new extension points.

Such configuration providers may use the ecr.app.id property and/or the ecr.config.uri property for locating the configuration of the application.

The default configuration provider is org.eclipse.ecr.application.internal.ConfigurationProvider which is using a directory to store the configuration which location can be configured through ecr.config.uri and which by default is pointing to ${ecr.home.dir}/config.

If no such configuration directory exists then the default configurator will use the built-in configuration packaged in bundle fragments.

Note: when using a custom configurator not located in a fragment of org.eclipse.ecr.application bundle, you must specify the full name of the configurator class including the bundle that contain the class as following bundleSymbolicName:fullClassName.

Example: org.eclipse.ecr.configurator.remote:org.eclipse.ecr.configurator.remote.RemoteConfigurator

Built-in configuration

The built-in configuration is packaged in bundle fragments and is useful in development mode. This approach is providing an application ready to be launched with and using the built-in configuration.

In that mode all the config directories found in fragments of the org.eclipse.ecr.application bundle are extracted and copied into ${ecr.home.dir}/tmp/config at each startup.

If you want to have a persistent configuration you can simply start once ECR and then copy the ${ecr.home.dir}/tmp/config generated directory into ${ecr.home.dir}/config. Then on next launch the default configurator will use the configuration in that directory.

To create a new configuration fragment to add built-in configuration just create a new fragment for the org.eclipse.ecr.application bundle and put inside a config directory which contains the configuration files.

Database configuration

The default configurator is checking the ecr.database property (which defaults to h2) to locate the right repository configuration files to use. Repository configuration files are located inside the config/db/${ecr.database} directory.

So, if you want to add a new repository configuration (let say for using mysql) you can add a configuration fragment containing the repository configuration inside config/db/mysql.

When you will start ECR using ecr.database=mysql, configuration files inside config/db/mysql will be used and any other directory inside config/db/ will be ignored.

Other configurator implementations must implement their own logic to choose the right configuration files depending on the system properties used to configure the ECR application.

ECR Application startup

The bundle org.eclipse.ecr.application plays an important role in the ECR application startup.

To be able to correctly start ECR you must configure the host OSGi framework to auto-start the org.eclipse.ecr.application bundle and to not auto-start any other ECR bundle.

The ECR bundles will be lazily loaded as the extensions and components in the application are installed.

So, when starting ECR the org.eclipse.ecr.application bundle is automatically started by the framework, then the activator of that bundle will load the application configuration and will start the component manager that will install any extension or component found in the application.

At the end of the startup process, the activator will notify all the registered ECR components that the application was started.

ECR Application listeners

As we've seen the org.eclipse.ecr.application bundle is responsible to configure and launch the ECR application.

If you need custom initialization or cleanup to be done you can implement an application listener and put it in a fragment of the org.eclipse.ecr.application and specify in the fragment MANIFEST.MF the application listener class to be used:

 ECR-ApplicationListener: org.eclipse.ecr.configuration.JettyConfigurator

This is how the jetty server used by the default ECR application is started.

The listener class must implement the interface org.eclipse.ecr.application.LifeCycleListener or extends the class org.eclipse.ecr.application.LifeCycleAdapter.

Application listeners will be called by the org.eclipse.ecr.application activator at each signifiant point in the application startup to let listeners do custom startup.

For example you can use such listeners to start services or containers like web servers, JCA containers etc or even to install extra plugins located in remote repositories.

Next: Go to the Content Repository section to learn what are the main functions of the ECR content repository.