Manifestdateien für Liberty-Features
Ein Liberty-Feature setzt sich aus einer Featuremanifestdatei und einer Sammlung von OSGi-Bundles zusammen, die Klassen und Services bereitstellen, die einer bestimmten Funktion in der Laufzeitumgebung des Liberty-Profils entsprechen. In der Manifestdatei finden Sie die Einführung in das Format eines Featuremanifests und in die Bedeutungen der einzelnen Header.
Die Featuremanifestdatei im Liberty-Profil verwendet das Metadatenformat des Subsystemservice aus der Spezifikation OSGi Enterprise R5. Ein Feature wird mithilfe einer Featuremanifestdatei (Datei mit der Erweiterung .mf) definiert, die im Verzeichnis lib/features gespeichert wird, und muss den angepassten Typ "subsystem" haben: osgi.subsystem.feature. Weitere Informationen zur OSGi-Manifestsyntax finden Sie im Abschnitt 1.3.2 der OSGi-Basisspezifikation.
Header | Beschreibung | Erforderlich? |
---|---|---|
Subsystem-ManifestVersion | Das Versionsformat für die Featuremanifestdatei. Dieser Header muss auf "1" gesetzt werden. | Nein |
Subsystem-SymbolicName | Der symbolische Name des Features sowie alle Attribute und Anweisungen. | Ja |
Subsystem-Version | Die Version des Features. Einzelheiten zur Definition finden Sie in der OSGi-Kernspezifikation im Abschnitt 3.2.5. | Nein |
Subsystem-Type | Der Subsystemtyp für das Feature. Momentan haben alle Features denselben Subsystemtyp: osgi.subsystem.feature. | Ja |
Subsystem-Content | Der Subsysteminhalt des Features. Hierbei handelt es sich um eine durch Kommas getrennte Liste mit Bundles und Subsystemen, die für die Ausführung dieses Features erforderlich sind. Wenn Sie die Konfiguration des automatischen Features in der Datei server.xml zulassen möchten, muss der Funktionsheader die erforderlichen Features enthalten und, und die Features müssen im Inhalt des Subsystems definiert sein. | Ja |
Subsytem-Localization | Die Position der Lokalisierungsdateien für das Feature. | Nein |
Subsystem-Name | Ein kurzer, lesbarer Name für das Feature. Dieser Wert kann lokalisiert sein. | Nein |
Subsystem-Description | Eine Beschreibung des Features. Dieser Wert kann lokalisiert sein. | Nein |
IBM-Feature-Version | Die Version dieses Subsystemtyps. Dieser Header muss auf "2" gesetzt werden. | Ja |
IBM-Provision-Capability | Der Funktionsheader, der beschreibt, ob ein Feature automatisch bereitgestellt werden kann. | Nein |
IBM-API-Package | Die API-Pakete, die Anwendungen von diesem Feature, von Features in anderen Produkterweiterungen und vom Liberty-Kernel bereitgestellt werden. | Nein |
IBM-API-Service | Die OSGi-Services, die dieses Feature OSGi-Anwendungen bereitstellt. | Nein |
IBM-SPI-Package | Die SPI-Pakete, die Features in anderen Produkterweiterungen und dem Liberty-Kernel von diesem Paket bereitgestellt werden. | Nein |
IBM-ShortName | Der Kurzname des Features. | Nein |
IBM-AppliesTo | Die Liberty-Version, für die dieses Feature gilt. | Nein |
Subsystem-License | Der Lizenztyp für dieses Feature. | Nein |
IBM-License-Agreement | Das Präfix der Position der Lizenzvereinbarungsdateien. | Nein |
IBM-License-Information | Das Präfix der Position der Lizenzinformationsdateien. | Nein |
IBM-App-ForceRestart | Gibt an, dass Anwendungen erneut gestartet werden sollen, wenn das Feature in einem aktiven Server installiert oder deinstalliert wird. | Nein |
Subsystem-SymbolicName
Die Syntax für diesen Header entspricht der Bundle-SymbolicName-Syntax für ein Bundle. Der Header enthält einen symbolischen Namen, der der Syntax für Paketnamen entspricht, und kann optional eine Reihe von Attributen und Anweisungen enthalten.
- superseded. Dieses Attribut gibt an, ob das Feature
durch Features oder Funktionselemente ersetzt wurde.
Das Attribut hat einen der folgenden Werte:
- true - Das Feature wurde ersetzt.
- false - Das Feature wurde nicht ersetzt.
Weitere Informationen finden Sie unter Ersetzte Features.
- superseded-by. Dieses Attribut gibt eine durch Kommas getrennte Liste mit Features an, die dieses Feature ersetzen (falls vorhanden), und es ist optional.
- visibility. Die gültigen Werte für diese Anweisung sind folgende:
- public - Das Feature wird als API eingestuft. Das Feature wird von den Entwicklertools zur Verwendung in der Datei server.xml und zur Ausgabe in Nachrichten unterstützt.
- protected - Das Feature wird als SPI eingestuft. Das Feature wird von den Entwicklertoolszur Verwendung in der Datei server.xml oder zur Ausgabe in Nachrichten nicht unterstützt. Das Feature wird bereitgestellt, damit Extender (Erweiterungsprogramme) es zur Erstellung von Features einer höheren Ebene verwenden können.
- private (Standardeinstellung) - Das Feature ist ein produktinternes Feature. Das Feature kann weder in der Datei server.xml verwendet, noch von Extender-Features referenziert werden. Das Feature kann jederzeit, auch zwischen Fixpacks, geändert werden.
Subsystem-SymbolicName: com.ibm.example.feature-1.0;
visibility:=public; superseded=true; superseded-by="com.ibm.example.feature-2.0"
IBM-ShortName: appSecurity-1.0
Subsystem-SymbolicName: com.ibm.websphere.appserver.appSecurity-1.0; visibility:=public;
superseded=true; superseded-by="appSecurity-2.0, [servlet-3.0], [ldapRegistry-3.0]"
Weitere Informationen finden Sie unter
Gesonderte Features.Subsystem-Content
Subsystem-Content ::= Inhalt ( ',' Inhalt )*
content ::= eindeutiger_Name ( ';' Parameter )*
unique-name ::= eindeutiger_Name (siehe Abschnitt 1.3.2 der OSGi-Kernspezifikation)
- version - Der Versionsbereich, der bei der Suche eines Bundles abgeglichen wird. Es werden nur Bundles aus diesem Bereich ausgewählt. Ein typisches Beispiel für einen Versionsbereich ist [1,1.0.100).
- type - Der Typ des bereitzustellenden Inhalts.
Sie können zur Angabe des Inhaltstyps einen beliebigen Wert angeben. Bei einigen Typen
werden Bundles im OSGi-Framework eines Servers, der das Feature verwendet, installiert und gestartet.
Bei allen Typen wird der Inhalt in ein Installationspaket eingeschlossen, das das Feature enthält.
Die folgenden Werte sind vordefiniert:
- osgi.bundle - Dieser Wert ist der Standardwert und zeigt ein OSGi-Bundle an, das im OSGi-Framework des Servers und in einem Installationspaket bereitgestellt werden soll.
- osgi.subsystem.feature - Dieser Wert zeigt an, dass das Feature im OSGi-Framework des Servers und in einem Installationspaket bereitgestellt werden soll. Diese Features müssen den im Header Subsystem-SymbolicName angegebenen Namen verwenden.
- jar - Dieser Wert zeigt an, dass eine JAR-Datei in ein Installationspaket eingeschlossen werden muss und mit einer Kombination aus Versionsbereich und/oder Positionswert ausgewählt wird.
- file - Dieser Wert zeigt an, dass die im Attribut location angegebene Datei in ein Installationspaket eingeschlossen werden muss.
- location - Die Position des Bundles. Für ein Bundle oder für einen JAR-Typ kann der Wert eine durch Kommas getrennte Liste mit Verzeichnissen sein, die die "spec"- und API-Bundles im Verzeichnis dev angibt, oder der Wert kann ein Einzeleintrag sein, der auf die JAR-Datei verweist. Wenn type auf file gesetzt ist, ist nur ein Einzeleintrag zulässig, der direkt auf die betreffende Datei verweist.
- start-phase - Die Startphase, in der das Bundle
beim Systemstart gestartet werden soll. Die Anweisung start-phase kann
einen der folgenden Werte haben:
- SERVICE - Dieser Wert gibt die früheste Phase an. Standardmäßig wird die Startphase 9 zugeordnet.
- CONTAINER - Hierbei handelt es sich um den Standardwert, wenn kein Wert für start-phase angegeben wird. Der Wert gibt die Containerphase an, in der die Anwendungscontainer gestartet werden. Standardmäßig wird die Startphase 12 zugeordnet.
- APPLICATION - Dieser Wert gibt die späteste Phase an, in der die Anwendungen Anwendungen gestartet werden.
Subsystem-Content: com.ibm.websphere.appserver.api.basics; version="[1,1.0.100)"; type=jar; location:="dev/api/ibm/,lib/",
com.ibm.websphere.appserver.spi.application;
location:="dev/spi/ibm/com.ibm.websphere.appserver.spi.application_1.0.0.jar"; type="jar",
com.ibm.websphere.appserver.spi.application_1.0.0-javadoc.zip;
location:="dev/spi/ibm/javadoc/com.ibm.websphere.appserver.spi.application_1.0.0-javadoc.zip"; type="file"






![[8.5.5.4 oder höher]](../ng_v8554.gif)
- ibm.executable - Diese Anweisung
fügt der zugeordneten Datei die Ausführungsberechtigung entsprechend der aktuellen umask-Einstellung hinzu,
wenn der Wert
auf "true" gesetzt wird.
Wird ein anderer Wert angegeben, wird keine Aktion ausgeführt.
In der folgenden Tabelle ist jeweils die
aktuelle umask und die Klasse, die die Ausführungsberechtigung erhält, aufgeführt.
Tabelle 2. Beispiele für umask-Werte und Klassen mit Ausführungsberechtigung, die mit ibm.executable festgelegt werden Umask Ausführungsberechtigung für die Klasse 022 owner, group, other 023 owner, group 055 owner
Subsytem-Localization
Dieser Header gibt die Position der Lokalisierungsdateien für das Feature an.
Subsystem-Localization: OSGI-INF/l10n/loc
Subsystem-Name
Verwenden Sie diesen Header, um einen kurzen, lesbaren Namen für das Feature anzugeben. Sie können eine Literalzeichenfolge oder einen Eigenschaftsnamen angeben. Wenn Sie einen Eigenschaftsnamen angeben, kann der Wert lokalisiert sein.
Subsystem-Name: %name
Der Wert für
name wird in einer Eigenschaftendatei an der mit dem Header
Subsytem-Localization angegebenen Position (loc.properties
im vorherigen Beispiel) im folgenden Format definiert:
name=Featurename
Subsystem-Description
Verwenden Sie diesen Header, um eine Beschreibung für das Feature anzugeben. Sie können eine Literalzeichenfolge oder einen Eigenschaftsnamen angeben. Wenn Sie einen Eigenschaftsnamen angeben, kann der Wert lokalisiert sein.
Subsystem-Description: %desc
Der Wert für
desc wird in einer Eigenschaftendatei an der mit dem Header
Subsytem-Localization angegebenen Position (loc.properties
im vorherigen Beispiel) im folgenden Format definiert:
desc=Featurebeschreibung
IBM-Provision-Capability
Automatische Features sind Features, die den Header IBM-Provision-Capability im Manifest enthalten. Dieser Header beschreibt andere Features, die bereitgestellt werden müssen, damit dieses Feature automatisch bereitgestellt wird. Verwenden Sie beim Auflisten der anderen Features den Header Subsystem-SymbolicName des Features. Wenn Features in der Datei server.xml konfiguriert sind, prüft die Laufzeit (runtime), ob die Voraussetzungen für automatisch bereitgestellte Features erfüllt werden. Ist dies der Fall, werden die Features automatisch bereitgestellt.
Im Format des Headers IBM-Provision-Capability werden OSGi-LDAP-Standardfilter verwendet.
IBM-API-Package
Mit diesem Header wird angegeben, welche API-Pakete für Anwendungen sichtbar sind. Die Syntax entspricht der Syntax des Headers Export-Package. Der Header enthält dementsprechend eine durch Kommas getrennte Liste mit API-Paketen, aber jedes API-Paket kann Attribute haben.
- type - Der Typ des API-Pakets. Das Attribut type kann
einen der folgenden Werte haben:
- spec - Gibt eine von einem Standardelement bereitgestellte API an, z. B. javax.servlet oder org.osgi.framework.
- ibm-api - Gibt eine von IBM® bereitgestellte API an, die einen Mehrwert liefert.
- api - Gibt eine benutzerdefinierte API an. Dies ist der Standardwert.
- third-party - Gibt eine API an, die zwar sichtbar ist, aber nicht von IBM gesteuert wird. Gewöhnlich handelt es sich hierbei um Open-Source-Pakete.
- internal - Gibt Pakete an, die keine API-Pakete sind, aber bereitgestellt werden müssen, damit Anwendungen funktionieren. Diese Pakete können verwendet werden, wenn Java™-Bytecode erweitert oder eingebunden wird, um zur Laufzeit Referenzen auf internen Code hinzuzufügen.
IBM-API-Package: javax.servlet; type="spec",
com.ibm.websphere.servlet.session; type="ibm-api",
com.ibm.wsspi.webcontainer.annotation; type="internal"
IBM-API-Service
Mit diesem Header werden die Services aus dem Feature angegeben, die für OSGi-Anwendungen sichtbar sind. Außerdem muss das Feature die Services in der OSGi-Service-Registry registrieren.
IBM-API-Service ::= Service ( ',' Service )*
service ::= service-name ( ';' attribute )*
service-name ::= unique-name
service-name ist
der Java-Klassenname oder -Schnittstellenname des
Service. Die Attribute werden als Serviceeigenschaften für die Services
interpretiert. IBM-API-Service: com.ibm.example.service.FeatureServiceOne;
myServiceAttribute=myAttributeValue,
com.ibm.example.service.FeatureServiceTwo
Wenn eine OSGi-Anwendung die vom Header IBM-API-Service bereitgestellten Services verwenden möchte, muss die Anwendung einen "blueprint"-Verweis auf den Service enthalten, damit der Service in der Anwendung bereitgestellt wird.
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<reference id="FeatureServiceOneRef"
interface="com.ibm.example.service.FeatureServiceOne" />
</blueprint>
Damit ein Service von einem Bundle in einer OSGi-Anwendung verwendet werden kann, muss das Schnittstellenpaket für das entsprechende Bundle verfügbar sein. Dies bedeutet, dass das Schnittstellenpaket im Header Import-Package in der Manifestdatei des konsumierenden Bundles angegeben sein muss. Außerdem muss das Schnittstellenpaket im Header Export-Package in einem Feature-Bundle und im Header IBM-API-Package der Feature-Manifestdatei angegeben sein. Der von einem Feature bereitgestellte Service muss in der OSGi-Service-Registry mit der OSGi-Serviceschnittstelle BundleContext oder mit einem anderen Verfahren wie Declarative Services oder Blueprint registriert sein. Weitere Informationen finden Sie unter OSGi-Bundle mit einfacher Aktivierung entwickeln und Erweiterte Features mit OSGi Declarative Services erstellen.
IBM-SPI-Package
Wenn Sie ein eigenes Liberty-Feature erstellen, installieren Sie es in die Benutzerprodukterweiterung. Alle Pakete in Ihrem Feature sind für alle anderen Features zugänglich, die in der Benutzerprodukterweiterung installiert sind. Wenn Sie jedoch möchten, dass ein Paket in Ihrem Feature für ein Feature zugänglich ist, das in einer anderen Produkterweiterung installiert ist, müssen Sie den Paketnamen im Header "IBM-SPI-Package" auflisten.
Alle im Header "IBM-SPI-Package" aufgelisteten Pakete müssen von einem Bundle im Liberty-Feature exportiert werden. Dazu müssen die Pakete im Header "Export-Package" der Bundlemanifestdatei aufgelistet werden.
IBM-ShortName
Dieser Header gibt einen Kurznamen für ein Feature an, mit dem Sie ein Feature in der Datei server.xml angeben können. Wenn die Manifestdatei keinen Header IBM-ShortName enthält, wird standardmäßig der Header Subsystem-SymbolicName verwendet. Der Header IBM-ShortName ist nur für öffentliche Features gültig.
IBM-AppliesTo
Produkt-ID; productVersion=Produktversion; productInstallType=Produktinstallationstyp; productEdition=Produkteditionen
Wenn Sie mehrere Einträge angeben, müssen Sie für jeden Eintrag eine andere Produkt-ID angeben.
Für Produkteditionen können Sie eine einzelne Edition oder eine durch Kommas getrennte Liste mit Editionen angeben, die Sie in Anführungszeichen einschließen.
IBM-AppliesTo: com.ibm.websphere.appserver; productVersion=8.5.5; productInstallType=Archive; productEdition="BASE,DEVELOPERS,EXPRESS,ND"
Subsystem-License
Dieser Header definiert den Lizenztyp für dieses Feature. Wenn Sie einen Wert für den Header "Subsystem-License" angeben, aber keine Werte für die Header "IBM-License-Agreement" und "IBM-License-Information", wird der Wert des Headers "Subsystem-License" während der Installation angezeigt, damit er vom Benutzer akzeptiert werden kann.
Wenn bereits ein Feature mit demselben Subsystem-License-Headerwert installiert ist, wird die Lizenz nicht angezeigt, und während der Installation wird keine Lizenzbestätigung angefordert. Wenn Abhängigkeiten im Header Subsystem-Content bedeuten, dass mindestens zwei Features installiert werden, die denselben Subsystem-License-Headerwert haben, muss der Benutzer die Lizenz während der Installation nur ein einziges Mal akzeptieren.
Subsystem-License: L-JTHS-93TMHH
Subsystem-License: http://www.apache.org/licenses/LICENSE-2.0.html
IBM-License-Agreement
Dieser Header gibt das Präfix für die Position der Lizenzvereinbarungsdateien an. Geben Sie den Dateipfad zu den Dateien LA_Sprache im Subsystemarchiv bis zum Zeichen "_" an. Geben Sie das Zeichen "_" selbst nicht an (der Sprachencode wird vom Installationstool angefügt). Wenn diese Lizenz nicht akzeptiert wurde, muss der Benutzer die Lizenz während der Installation des Features akzeptieren. Die Lizenzdateien werden in das Liberty-Installationsverzeichnis kopiert.
IBM-License-Agreement: lafiles/LA
IBM-License-Information
Dieser Header gibt das Präfix für die Position der Lizenzinformationsdateien an. Geben Sie den Dateipfad zu den Dateien LI_Sprache im Subsystemarchiv bis zum Zeichen "_" an. Geben Sie das Zeichen "_" selbst nicht an (der Sprachencode wird vom Installationstool angefügt). Wenn diese Lizenz nicht akzeptiert wurde, muss der Benutzer die Lizenz während der Installation des Features akzeptieren. Die Lizenzdateien werden in das Liberty-Installationsverzeichnis kopiert.
IBM-License-Information: lafiles/LI
IBM-App-ForceRestart
- install - Anwendungen erneut starten, wenn das Feature installiert wird.
- uninstall - Anwendungen erneut starten, wenn das Feature deinstalliert wird.
- install,uninstall - Anwendungen erneut starten, wenn das Feature installiert oder deinstalliert wird.
Beispielfeaturemanifestdatei
<featureManager>
<feature>usr:example-1.0</feature>
</featureManager>
Die Konfiguration dieses Features in einem Server führt dazu, dass das angegebene
Bundle com.ibm.example.bundle1
im OSGi-Framework der Serverlaufzeitumgebung installiert und gestartet wird.
Das einzelne API-Paket com.ibm.example.publicapi
ist für alle Anwendungen in diesem Server mit Ausnahme von
Java-EE-Anwendungen verfügbar, für die der Pakettyp
api nicht sichtbar ist.
OSGi-Anwendungen müssen das Paket explizit importieren, wenn sie es verwenden möchten.
Die beiden SPI-Pakete com.ibm.example.spi.utils
und com.acme.spi.spiservices sind wie das API-Paket für sämtlichen
Feature-Code im Server sichtbar.
IBM-Feature-Version: 2
Subsystem-ManifestVersion: 1.0
Subsystem-SymbolicName: com.ibm.example-1.0; visibility:=public
Subsystem-Version: 1.0.0.qualifier
Subsystem-Type: osgi.subsystem.feature
Subsystem-Content: com.ibm.example.bundle1; version="1.0.0"
Subsystem-Localization: OSGI-INF/l10n/loc
Manifest-Version: 1.0
Subsystem-Name: %name
Subsystem-Description: %desc
IBM-API-Package: com.ibm.example.publicapi; type="api"
IBM-SPI-Package: com.ibm.example.spi.utils, com.ibm.example.spi.spiservices
IBM-ShortName: example-1.0