THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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.openamqapache.qpid.brokerserver.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.
...
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:
...
Broker configuration is accessed through the class in the org.apache.qpid.server.configuration, primarily starting at ServerConfiguration and retrieving values or other Configuration classes from there.
| Include Page | ||||
|---|---|---|---|---|
|
...
Example
An example should make this clearer. Consider a (fictional) configuration file containing the following XM
| Code Block | ||
|---|---|---|
| ||
<qpid>
<connector>
<ssl>true</ssl>
<port>5672</port>
</connector>
</qpid>
|
To use this in the application we would define a class to represent it:
| Code Block | ||
|---|---|---|
| ||
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:
| Code Block | ||
|---|---|---|
| ||
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:
...
Option
...
Long Option
...
Description
...
b
...
bind
...
Bind to the specified address overriding any value in the config file
...
c
...
config
...
Use the given configuration file
...
h
...
help
...
Prints list of options
...
l
...
logconfig
...
Use the specified log4j.xml file rather than that in the etc directory
...
p
...
port
...
Specify port to listen on. Overrides value in config file
...
v
...
version
...
Print version information and exit
...
w
...
logwatch
...
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.
...