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.
- 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.
- 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.
- In the
IBM-API-Package
header, list
the packages that are to be exposed on the default class loader for
applications.
- 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>