Qpid Design - Configuration

Configuration Methods

QPID supports two methods of configuration:

1. command line switches (e.g. passing a -p flag on startup to specify the port)
2. configuration file

It is intended that the configuration file will be used for nearly all configuration but that some very common or useful options are exposed using command line switches.

CLI

QPID uses Commons CLI to parse command line arguments. It provides the following features:

• Ability to parse both short and long flags (e.g. -p and --port) and treat them as the same logical option
• Generation of well formatted usage messages
• Ability to specify configuration options in different ways, such as from files or from system properties, which can help when writing unit tests

The result of parsing options, however they are specified, is a CommandLine object which can then be queried to find out specific values. Currently this is done in org.openamq.broker.Main and the CommandLine object is not exposed elsewhere but if it does require to be more widely used it could be added to the ApplicationRegistry. However it is strongly recommended that the configuration approach in the follow section is used where possible.

Configuration File

QPID uses Commons Configuration to handle nearly all configuration. It provides methods that allow parsing of options from a range of sources, including configuration files, system properties or simply hard coded classes of values (which is very useful in unit test cases).

The file format used by QPID is XML, and Commons Configuration allows a very simple XPath-like syntax to query individual elements from the configuration file.

In order to make using configuration as non-intrusive, flexible and strongly-typed as possible we do the following:

• Create classes representing configuration options for a particular component. For example, we have an object to represent all the connection (transport) configuration options. That object is used by the transport-related code rather than dealing with the Commons Configuration objects directly. As well as being strongly typed and easily used in unit tests, this means that a developer can see all the configuration options related to a particular feature in one place.
• To make it easier to map between elements in the configuration file and fields in the configuration objects, a Configurable annotation (Java 5 annotation) is applied to the fields in the configuration object which contains the path expression in the configuration file, and default values should no value be specified
• The configuration objects are stored in the ApplicationRegistry
• The commons configuration object is stored in the ApplicationRegistry allowing "direct access" to the raw options should this be required

Example

An example should make this clearer. Consider a (fictional) configuration file containing the following XM

<qpid>
  <connector>
    <ssl>true</ssl>
    <port>5672</port>
  </connector>
</qpid>

To use this in the application we would define a class to represent it:

public class ConnectionConfig
{
    public static final String SSL_PORT = "8672";

    @Configured(path = "connector.port",
                defaultValue = DEFAULT_PORT)
    public int port;

    @Configured(path = "connector.ssl",
                defaultValue = "false")
    public boolean enableSSL;
}

Note the use of @Configured to define the mapping between the configuration file and the field values.

All we need to do the access this configuration object anywhere within the application is call:

ConnectionConfig cfg = ApplicationRegistry.getInstance().getConfiguredObject(ConnectionConfig.class);

The ApplicationRegistry is documented elsewhere but from the configuration perspective all you need to know is that the first time getConfiguredObject is called for a particular class, the configuration file is parsed and the configuration object is stored for future use. Subsequent calls to getConfiguredObject for the same class are very cheap since only a hash table lookup is done.

Command Line Options

The following options are available:

Logging

Logging is handled slightly differently. The main reason for this is that logging is something we want configured before the main configuration file is processed.

The broker uses log4j as the logging implementation, and configuration must be done using the more expressive XML format. A couple of command line switches are used to configure logging:

• -l, --logconfig specifies the log configuration file to use. By default it looks for a file called log4j.xml located in the same directory as the config.xml file
• -w, --logwatch the interval in seconds to poll the log configuration file for changes. The default is 60 seconds and zero means do not poll for changes.

By using the logwatch option it is possible to make changes to the logging configuration at runtime without restarting the broker. (For example, enabling more logging on certain packages in order to diagnose a problem).