Developing a Liberty feature manually

You can create a Liberty feature manually and install it to Liberty.

About this task

A feature can consist of a single OSGi bundle and a feature manifest file. This example makes a library available to applications so that the external packages are visible on the default application class path. By copying the feature manifest into the ${wlp.user.dir}/extension/lib/features directory, and the OSGi bundle into the ${wlp.user.dir}/extension/lib directory, the feature can be installed to Liberty. Then you can use the feature in your server.xml file.

For details about the format of a feature manifest file, see Liberty feature manifest files.

This example describes how to construct a Liberty feature manually. Alternatively, you can use the WebSphere® Application Server Developer Tools. See Creating a Liberty feature by using developer tools.

Procedure

To create a Liberty feature manually, complete the following steps:

Create an OSGi bundle containing your Java™ classes, and a bundle manifest file with appropriate OSGi headers, for example to export the Java packages that you want 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"
```
Use the jar command to package the Java classes and the feature manifest file. For example:
```
jar cfm samplebundle.jar MANIFEST.Mf *.class
```
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. Best practice: Add the optional manifest headers to indicate the applicable version of the subsystem specification (Subsystem-ManifestVersion), the version of your feature (Subsystem-Version), and a short name of your feature (IBM-ShortName). Specifying these values will help you to evolve your 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 you create your Liberty feature, you install it into the user product extension, and the packages in your feature can be accessed by any other feature that is 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
```
Copy the bundle into the ${wlp.user.dir}/extension/lib directory.
Copy the feature manifest into the ${wlp.user.dir}/extension/lib/features directory.
If you 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 your feature is installed to Liberty, you can add the feature name to the list of configured feature in your server.xml file. For example:

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