14 Configuration

14.1 Introduction

An application often has a number of configurable items: connection settings for a database or SMTP server, the path to the company logo, connection limits, port numbers, date formatting patterns, passwords for external services (e.g. Google maps API key), and so on.

Configurability is useful both for company-internal usage (e.g. different configurations for different deployments) and standard applications installed by many users.

As applications become bigger and are composed of lots of modules, each of the modules might have its configuration requirements.

Rather than letting developers invent a configuration technique on the spot (property files, system properties, ...), Kauri offers a default solution, bringing both homogeneity and a larger feature set. Some of its features include:

• Configuration can be defined per module (it is not one big configuration file), a module can only see its own configuration. If there are multiple instances of the same module, each instance has its own configuration.
• One-stop location for configuration: the same configuration system is used for configuring modules (Kauri-provided or user-written) and for Kauri (the runtime) itself.
• The configuration data format is a simple tree structure, rather than a flat set of properties. There is a convenient API for accessing the configuration data, a lot easier than, say, an XML DOM tree.
• Configuration gets refreshed periodically at runtime, it is possible to register configuration-change listeners.
• Configuration inheritance: a module can contain a default built-in configuration, which can be overridden by user-provided configuration. The user can also specify multiple configuration locations, between which fallback will happen, e.g. a 'development' configuration can fallback to a 'common' configuration and finally to the module built-in configuration.