+

Search Tips   |   Advanced Search

Server configuration

The Liberty profile is configured by default. The runtime environment operates from a set of built-in configuration default settings, and we only need to specify any configuration that overrides those default settings. We do this by editing either server.xml, or another XML file included in server.xml at run time.

The configuration has the following characteristics:

  • Features are the units of functionality for the runtime environment loaded into a particular server. They are the primary mechanism that makes the server composable. The list of features specified in the server configuration provides a functional server.

    When we first install and start the server, a feature manager and a default server configuration are available:

    • By default, a server contains the jsp-2.2 feature, to support servlet and JSP applications. We can use the feature manager to add the features needed.

    • Server configuration is by exception. When we specify the features needed, the default configuration of those features provides a rich environment designed to cover most common requirements, therefore we only need to specify changes from the default configuration.

    For a full list of the elements that we can configure to complement or modify the configuration provided by Liberty features, see Configuration elements in server.xml.

    We can also use a bootstrap.properties file to specify properties 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.


    Service author perspective: Runtime management of configuration

    The Liberty profile configuration service parses the primary server.xml file and any files it includes, 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 our owning service. It is therefore important that the services can receive, and respond appropriately to, updates to their configuration at any time that 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 Enable a service to receive configuration data.


    Subtopics

    • Configuration elements in server.xml
      The application server configuration is described in a series of elements in server.xml. Each element has one or more attributes or sub-elements. This topic contains details of the possible elements, attributes, and sub-elements that can be configured.


    Parent topic: WebSphere Application Server Liberty Core: Overview

    Tasks:
    Specify Liberty profile bootstrap properties
    Edit the Liberty profile configuration using developer tools
    Add and remove Liberty features
    Administer the Liberty profile manually
    Use include elements, variables, and Ref tags in configuration files
    Localizing the configuration metadata
    Enable a service to receive configuration data
    Coding the service to receive configuration properties
    Associate a service with a persisted identity
    Describing configuration using the OSGi Metatype service
    Customize the Liberty profile environment

    Reference:

  • Liberty features