+

Search Tips   |   Advanced Search

Feature management

Features are the units of functionality for the runtime environment loaded into a particular server.

Use the configuration file server.xml to declare which features to load. The set of features is enclosed within the <featureManager> element, and each feature within the <feature> subelement. For example: 

<server>
  <featureManager>
    <feature>servlet-3.0</feature>
    <feature>localConnector-1.0</feature>
  </featureManager>
</server>

We can specify any feature in the server configuration file. Some features include other features within them. The same feature can be included in one or more other features. At run time, the feature manager computes the combined list of content that is required to support the requested set of features.

For information about the main available features, see Liberty features. For information about the restrictions that apply to each feature, see Runtime environment known restrictions.


Dynamic changes to feature configuration

When we change the feature configuration, the feature manager recalculates the list of required bundles, stops and uninstalls those bundles that are no longer required, and installs and starts any additions. All features are therefore designed to cope with other features that are being dynamically added or removed.

Singleton Features

With the delivery of the first set of features for Java EE 7, there are now two versions of the same feature:

Unlike other application servers, we can choose which version of this feature to use in a server configuration. servlet-3.0 preserves behavior for existing applications, while servlet-3.1 provides new capabilities for new or modified applications. With this choice of specification versions, no additional configuration properties are required, or provided, to control individual differences between the two versions.

The servlet feature is a singleton feature, which means that we can configure only one version for use in a server: either servlet-3.0 or servlet-3.1. If we have applications that need different versions of the servlet feature, we must deploy them in different servers. Many other features include the servlet feature as a dependency. In the WebSphere Liberty product, these features have been updated to work with either version. This ensures that we can configure a complete "stack" of features when we use servlet-3.1, but features from other sources might not have been updated to "tolerate" servlet-3.1. To enable features to "tolerate" servlet-3.1, modify the feature manifest as follows:

If the server configuration includes multiple versions of a singleton feature, either through direct configuration in server.xml, or through feature dependencies, that configuration is in error and neither version of that feature is loaded. This error results in a message similar to the following:

To resolve this problem, ensure that the configured features all specify, or tolerate, the same version of that singleton feature. If we have hard requirements on both feature versions, we must move some of our applications to a different server.


Superseded features

The superseded label on a feature indicates that a new feature or a combination of features might provide an advantage over using the superseded feature. For example, new, finer-grained features might be used in place of the superseded one in order to reduce the server footprint by excluding content that might not be necessary. The new feature or features might not completely replace the function of the superseded feature, so we must consider your scenario before deciding whether to change the configuration. Superseded features remain completely supported and valid for use in the configuration; the superseded label just provides an indication that we might be able to improve the configuration.

Very occasionally, a feature that includes other features is superseded by a new version of the feature that does not include all those features; the features that are not included in the new version are considered to be separated. If our application needs to use the functions of a separated feature, you must explicitly add the separated feature to the configuration.

For example, featureA and featureB have the following conditions:

If the application uses featureB functions, either of these configurations will work:


Parent topic: WebSphere Application Server Liberty Core: Overview

Tasks:

  • Add and remove Liberty features

    Reference:

  • Liberty features