Feature overview

Features are the discrete units of functionality by which you control the pieces of the runtime environment that are loaded into a particular server. By adding or removing features from your server configuration, you can control what functions the server can perform. Features provide the programming models and services that applications require. You can specify any feature in the server configuration files. Some features include other features within them, and the same feature might be included in one or more other features.

When the server is started, the JVM is launched and control is passed to the Open Liberty kernel. The configuration is loaded as described in the server configuration overview. When the configuration is parsed, the feature manager gains control and processes the featureManager configuration to load the requested features into the server and start the required components. Finally, the applications are started. When the configuration is changed, the feature manager reevaluates the code that is required for the newly requested features by starting and stopping parts of the runtime as necessary without restarting the server. Changes to applications are processed in a similar way.

Using features

Features are specified in the system configuration files that are the server.xml file and any other included files. The feature manager is configured by using the featureManager element in the server.xml file. Each feature that is required is configured by using the feature element. The following example configures the servlet-4.0 and jdbc-4.3 features:


The runtime contains default configuration settings so that the configuration you need to specify is kept to a minimum. Specify the features that you need, along with any additions or overrides to the default settings, in the server.xml file. For details about the server configuration, see the server configuration overview.

Zero migration

With the Open Liberty zero migration architecture, you can move to the latest version of Open Liberty with minimal impact to your current applications and configurations. Zero migration architecture means that you can use existing, unmodified configuration and application files with an updated version of the Open Liberty runtime environment without unwanted or unexpected change in behavior.

With the use of pluggable features in the Open Liberty runtime environment, your existing APIs and behaviors are supported in new product versions, and new APIs and behaviors are added in new features. For example, both the Servlet 3.1 and 4.0 specifications are supported. An API behavior change is made available as a new version of a feature so that you can choose the appropriate feature version for your application. These versioned features continue to be supported across Open Liberty updates.

If you continue to use the same feature version, you never need to migrate your application. For example, if your application uses Servlet 3.1, the Open Liberty server that runs the application must have the servlet-3.1 feature. You can update Open Liberty and continue to use the servlet-3.1 feature indefinitely, regardless of how many other Servlet specification levels are supported. You need to migrate your applications only if you choose to use the servlet-4.0 feature instead.

Combining features

If you try to configure a server to have different versions of a feature, an error is reported because Open Liberty doesn’t support combining different versions of the same feature. This means that most Open Liberty features are singleton features. A singleton feature is a feature for which you can configure only one version for use in a server.

If you have applications that need different versions of the singleton feature, you must deploy them in different servers. If your server configuration includes multiple versions of a singleton feature, either through direct configuration in the server.xml file, or through feature dependencies, that configuration is in error and neither version of that feature is loaded. To resolve this problem, ensure that the configured features all specify, or tolerate, the same version of that singleton feature. If you have hard requirements on both feature versions, you must move some of your applications to a different server.

Liberty doesn’t support combining features from both Java EE 7 and Java EE 8, except when the Java EE 7 and Java EE 8 specifications share a component specification version. If you combine Java EE 7 and Java EE 8 features in a server configuration, the server reports errors at startup.

The following features are included in both Java EE 7 and Java EE 8:

For a complete list of features that support Java EE 7, see the javaee-7.0 feature. For a complete list of features that support Java EE 8, see the javaee-8.0 feature.

Superseded features

If a feature is superseded, a new feature or a combination of features might provide an advantage over the superseded feature. The new feature or features might not completely replace the function of the superseded feature, so you must consider your scenario before you decide whether to change your configuration. Superseded features remain supported and valid for use in your configuration, but you might be able to improve your configuration by using the newer features.

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 your application depends on the functions of a separated feature, you must explicitly add the separated feature to your configuration.

The following table lists the Open Liberty features that are superseded:

Superseded feature Superseding feature Dependent feature removed



The ldapRegistry-3.0 and servlet-3.0 features were removed from the definition of the appSecurity-2.0 feature.


jms-2.0 and mdb-3.2

Together, the jms-2.0 and mdb-3.2 features provide the same function as the jmsMdb-3.2 feature.



The ssl-1.0 and transportSecurity-1.0 features are functionally equivalent. However, ssl-1.0 implies that an insecure network protocol is used, so transportSecurity-1.0 supersedes it.