+

Search Tips   |   Advanced Search

Develop a Liberty feature manually

We can create a Liberty feature manually and install it to the Liberty profile.

A feature can consist of a single OSGi bundle and a feature manifest file. This example makes a library available to applications so the external packages are visible on the default application class path. By copying the feature manifest into...

...and the OSGi bundle into...

...the feature can be installed to the Liberty profile. Then we can use the feature in server.xml.

This example describes how to construct a Liberty feature manually. Alternatively, we can use the WebSphere Application Server Developer Tools; see Create a Liberty feature using developer tools.

To create a Liberty feature manually:

  1. Create an OSGi bundle containing the Java classes, and a bundle manifest file with appropriate OSGi headers, for example to export the Java packages to expose to applications. Bundle-SymbolicName is the only required header; this entry specifies a unique identifier for a bundle, based on the reverse domain name convention. It is good practice to specify a version for the bundle, and in this example some Java packages are exported for application use: 
    Bundle-SymbolicName: com.usr.samplebundle
Bundle-Version: 1.0.1
Export-Package: com.usr.samplebundle.pkg1; version="1.0.0", 
                com.usr.samplebundle.pkg2; version="1.0.1"

  2. Use the jar command to package the Java classes and the feature manifest file. For example:

      jar cfm samplebundle.jar MANIFEST.Mf *.class

  3. Create a feature manifest file named feature-name.mf which describes the feature to the runtime environment.

    1. Provide the required manifest headers:

      • Subsystem-SymbolicName to specify the identity and visibility of the feature;

      • Subsystem-Content to locate the files that comprise the feature;

      • IBM-Feature-Version to identify which version of feature support is required by the runtime environment.

    2. Add the optional manifest headers to indicate the applicable version of the subsystem specification (Subsystem-ManifestVersion), the version of the feature (Subsystem-Version), and a short name of the feature (IBM-ShortName). Specifying these values will help you to evolve the feature in the future.

    3. In the IBM-API-Package header, list the packages that are to be exposed on the default class loader for applications.

    4. Optional: When we create the Liberty feature, you install it into the user product extension, and the packages in your feature can be accessed by any other feature installed to the user product extension. To make one or more SPI packages available to features in other product extensions, list the packages in the IBM-SPI-Package header. 

    Subsystem-ManifestVersion: 1.0
Subsystem-SymbolicName: com.example.myfeature.sample-1.0; visibility:=public
Subsystem-Version: 1.0.0.qualifier
Subsystem-Type: osgi.subsystem.feature
Subsystem-Content: samplebundle; version="[1,1.0.100)"
IBM-Feature-Version: 2
IBM-API-Package: com.usr.samplebundle.pkg1; type="api",              com.usr.samplebundle.pkg2; type="api"
IBM-SPI-Package: com.sample.myservice.spi;
IBM-ShortName: sample-1.0

  4. Copy the bundle into the ${wlp.user.dir}/extension/lib directory.

  5. Copy the feature manifest into the ${wlp.user.dir}/extension/lib/features directory.

  6. If we have defined Subsystem-Name and Subsystem-Description headers in the feature manifest file, and have localized the values, copy the localization files specified in the Subsytem-Localization header into the ${wlp.user.dir}/extension/lib/features/l10n directory.


Results

After the feature is installed to the Liberty profile, we can add the feature name to the list of configured feature in our server.xml file. For example: 

<featureManager>
     <feature>usr:sample-1.0</feature>
</featureManager>


Subtopics


Parent topic: Develop a Liberty feature

Tasks:

  • Create a Liberty feature using developer tools