Server configuration
Liberty is configured by exception. The runtime environment operates from a set of built-in configuration default settings, and you only need to specify configuration that overrides those default settings. You do this by editing either the server.xml file or another XML file that is included in server.xml at run time.
- Described in XML files.
- Human-readable, and editable in a text editor.
- Small, easy to back up, and easy to copy to another system.
- Shareable across an application development team.
- Composable, so that features can easily add their own configuration to the system.
- Extensibly-typed, so you don't have to modify the current configuration to work with later versions of the runtime environment.
- Dynamically responsive to updates.
- Forgiving, so that missing values are assumed and unrecognized properties are ignored.
Features are the units of functionality by which you control the pieces of the runtime environment that are loaded into a particular server. They are the primary mechanism that makes the server composable. The list of features that you specify in the server configuration provides a functional server. See Liberty features.
- By default, a server contains the
jsp-2.2feature, to support servlet and JSP applications. You can use the feature manager to add the features that you need. - Server configuration is by exception. When you specify the features that you need, the default configuration of those features provides a rich environment that is designed to cover most common requirements, therefore you only need to specify changes from the default configuration.
For a full list of the elements that you can configure to complement or modify the configuration provided by Liberty features, see Liberty features.
You can also use a bootstrap.properties file to specify properties that are needed before the main configuration is processed, and to define variables that are used in the main configuration.
For a complete list of configuration files, see Directory locations and properties.
Service author perspective: Runtime management of configuration
The Liberty configuration service parses the primary server.xml file and any files it includes, as well as the configuration files in the configDropins directory, merges the contents over the default configuration values provided by the installed bundles, then feeds the resulting property sets into the OSGi Configuration Admin Service (CA). CA injects each set of properties into the service that owns the set, if it is registered with CA.
The ordering of these steps is flexible. Services can register with CA before or after the initial property sets are established. Properties can be updated in CA after the initial injection, at which time the updated properties are injected into the owning service. It is therefore important that the services can receive, and respond appropriately to, updates to their configuration at any time when the service is active. Specifically, if a service delays its activation until its configuration is available, it must still be able to activate.
To enable a service to receive configuration data, there are a number of steps involved. See Enabling a service to receive configuration data.