Runtime services provide their configuration defaults so that the configuration you need to specify is kept to a minimum. At server startup, or when the user configuration files are changed, the kernel parses your configuration and applies it over the system defaults. The set of configuration properties belonging to each service is injected into the service each time the configuration is updated.
A Liberty profile server can be customized using a few simple files:
The primary configuration file for the Liberty profile server. This file is the one non-optional configuration file. It has a simple XML format that is suitable for text editors.
An optional text file used to customize the kernel bootstrap process or to specify additional
variables for use in
An optional file used to specify JVM options for the server. If this file is present, it
jvm.options file in the
/etc directory (only one file is used).
An optional file used to customize environment variables used to launch the server. If both
this file and the
/etc/server.env file are present, the contents of both are merged together
with values specific to the server superseding values specified for the installation.
The optional files are not created by default, whereas
server.xml is always created.
To effectively manage the configuration files of multiple servers, the administrator can create a globally accessible file share where the configuration files reside. Each server has access to this file share and uses it as its main configuration repository. A similar solution can be applied to a shared application's directory, so only one version of the application is used by all Liberty profile servers.
These techniques enable the administrator to control the server runtime configuration from a single place. For environments where there are multiple administrators with different roles who manage different aspects of the server, the configuration of the server can be placed in separate files. Each file contains configuration fragments dedicated to a given administrator and is referenced by the main configuration file using the include tag, as illustrated in figure below:
Authorization to the configuration files can be achieved on the operating system level. For example, a deployer has access to use a shared applications directory and has permissions to write to the
apps.xml file. Similarly, the configuration of the user registry can be
dedicated to a separate user who is authorized to the