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 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 Java Servlets 4.0 (servlet-4.0) and Java Database Connectivity 4.3 (jdbc-4.3) features:

<server>
  <featureManager>
    <feature>servlet-4.0</feature>
    <feature>jdbc-4.3</feature>
  </featureManager>
</server>

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.

Convenience features

You can enable a whole set of features all at once by specifying one of the convenience features. Convenience features automatically enable all the individual Open Liberty features that are associated with a particular platform or functional area. For example, the Jakarta EE Platform feature enables all the features that are part of the Jakarta EE Platform. The Jakarta EE Web Profile feature enables only those features that are part of the Jakarta EE Web Profile. A list of all the features that a convenience feature enables is provided on the reference page for each convenience feature. Enable the convenience features by adding them to the featureManager element in your server.xml file.

The following convenience features are available for the for Jakarta EE platform.

The Jakarta EE Platform feature enables all features that support the Jakarta EE platform.
The Jakarta EE Web Profile feature enables only features that support the lightweight Jakarta EE Web Profile.
The Jakarta EE Application Client feature enables all features that support the Jakarta EE Application Client functions.

Similar convenience features are available for the Java EE platform.

Open Liberty also provides two more convenience features.

The MicroProfile convenience feature enables all the Open Liberty features that support the MicroProfile platform.
The Jakarta Enterprise Beans convenience feature automatically enables all Open Liberty features that support enterprise beans functions.

Zero-migration architecture

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. 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. 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 more information about zero migration with Open Liberty, see Zero-migration architecture.

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.

Open 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 Java EE Full Platform 7.0 feature. For a complete list of features that support Java EE 8, see the Java EE Full Platform 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

Superseded feature	Superseding feature	Dependent feature removed
Application Security 1.0 (`appSecurity-1.0`)	Application Security 2.0 (`appSecurity-2.0`)	The LDAP User Registry 3.0 feature (`ldapRegistry-3.0`) was removed from the definition of the Application Security 2.0 feature.
JMS Message-Driven Beans 3.2 (`jmsMdb-3.2`)	Java Message Service 2.0 (`jms-2.0`) and Message-Driven Beans 3.2 (`mdb-3.2`)	Together, the Java Message Service 2.0 and Message-Driven Beans 3.2 features provide the same function as the JMS Message-Driven Beans 3.2 feature.
Secure Socket Layer 1.0 (`ssl-1.0`)	Transport Security 1.0 (`transportSecurity-1.0`)	The Secure Socket Layer 1.0 and Transport Security 1.0 features are functionally equivalent. However, the Secure Socket Layer 1.0 feature implies that an insecure network protocol is used, so the Transport Security 1.0 feature supersedes it.

Application Security 1.0 (appSecurity-1.0)

Application Security 2.0 (appSecurity-2.0)

The LDAP User Registry 3.0 feature (ldapRegistry-3.0) was removed from the definition of the Application Security 2.0 feature.

JMS Message-Driven Beans 3.2 (jmsMdb-3.2)

Java Message Service 2.0 (jms-2.0) and Message-Driven Beans 3.2 (mdb-3.2)

Together, the Java Message Service 2.0 and Message-Driven Beans 3.2 features provide the same function as the JMS Message-Driven Beans 3.2 feature.

Secure Socket Layer 1.0 (ssl-1.0)

Transport Security 1.0 (transportSecurity-1.0)

The Secure Socket Layer 1.0 and Transport Security 1.0 features are functionally equivalent. However, the Secure Socket Layer 1.0 feature implies that an insecure network protocol is used, so the Transport Security 1.0 feature supersedes it.