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 Liberty-Laufzeitumgebung entsprechen. In der Manifestdatei finden Sie die Einführung in das Format eines Featuremanifests und in die Bedeutungen der einzelnen Header.
Die Featuremanifestdatei in Liberty verwendet das Metadatenformat des Subsystemservice aus der Spezifikation OSGi Enterprise R5. Ein Feature wird mithilfe einer Featuremanifestdatei, einer .mf-Datei, 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 oder nicht 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 |
Subsystem-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 im Artikel Abgelöste Liberty-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 unterstützt. Es kann in der Datei server.xml verwendet werden und wird in Nachrichten ausgegeben.
- protected - Das Feature wird als SPI eingestuft. Das Feature wird nicht von den Entwicklertools unterstützt. Es kann nicht in der Datei server.xml verwendet werden und wird nicht in Nachrichten ausgegeben. 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.- singleton. Die gültigen Werte für diese Anweisung sind folgende:
- True. Das Feature ist ein Singleton.
- False. Das Feature ist kein Singleton.
Die singleton-Anweisung ist optional. Der Standardwert ist False.
Diese Anweisung wird verwendet, um anzugeben, dass ein bestimmtes Feature ein Singleton ist. Singleton bedeutet, dass nur eine Version eines angegebenen Features zur gleichen Zeit in die Laufzeit geladen werden kann. Standardmäßig sind Features keine Singletons. Wenn das Feature ein Singleton ist und mehrere Versionen eines angegebenen Features von der Serverkonfiguration erfordert werden, versucht die Laufzeit eine gemeinsame Version zu finden, die von allen erforderlichen Features toleriert wird. Weitere Informationen zur Versionstolerierung finden Sie in der ibm.tolerates-Anweisung unter "Subsystem-Content".
Wenn ein Feature ein Singleton ist, wird der Wert für den symbolischen Namen im folgenden Format angegeben: "<Name_des_Singleton-Features >-<Singletonversion>". Hierbei werden der Name und die Versionsangabe durch einen Bindestrich voneinander abgetrennt. Der Name des Singleton-Features kann Bindestriche enthalten. Die Zeichen jedoch, die hinter dem letzten Bindestrich stehen, werden als Singletonversion interpretiert. Wenn die Zeichen, die hinter dem letzten Bindestrich stehen, keiner gültigen Versionsangabe entsprechen, wird die Singletonversion 0.0.0 und der vollständige symbolische Name als Singletonname verwendet. Die Singletonversion wird bei der Vearbeitung der Anweisung "ibm.tolerates" unter dem Header "Subsystem-Content" verwenden. Beispiel:Subsystem-SymbolicName: com.ibm.example.feature-1.0; visibility:=public; singleton:=true
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 muss.
- osgi.subsystem.feature - Dieser Wert zeigt an, dass das Feature im OSGi-Framework des Servers und in einem Installationspaket bereitgestellt werden muss. 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 einen Suchpfad darstellen. Dieser Wert kann für jeden Typ möglicherweise ein einzelner Eintrag sein, der direkt auf die Ressource zeigt und der als Datei-URL angegeben sein kann. Pfade können absolut oder relativ sein. Relative Pfade werden relativ zur Position der Produkterweiterung mit dem Feature aufgelöst. Für ein Benutzerfeature wird das Standardprodukterweiterungsverzeichnis ${wlp.user.dir}/extension verwendet. Die Position für Produkterweiterungen, die keine Standarderweiterungen sind, wird über die Eigenschaft com.ibm.websphere.productInstall in der zugehörigen Eigenschaftendatei angegeben, die sich im Verzeichnis ${wlp.install.dir}/etc/extensions
befindet. Beispiel:
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"
- start-phase - Die Startphase, in der das Bundle
beim Systemstart gestartet werden muss. 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.
- ibm.tolerates - Gibt die alternative Singletonversion oder Versionen eines Singleton-Features , type=osgi.subsystem.feature, an, die beim Auftreten von Versionskonflikten im System bereitgestellt werden sollen.
Mit "unique-name" wird der symbolische Name der bevorzugten Version eines Singleton-Features angegeben. Wenn bekannt ist, dass das einzuschließende Feature mit anderen Singletonversionen eines angegebenen Singleton-Features verwendet werden kann, können Sie diese Singletonversionen mithilfe der Anweisung ibm.tolerates angeben. Dies erhöht die Kompatibilität für das definierende Feature für den Fall, dass andere Features für ein angegebenes Singleton-Feature nicht kompatible Versionswerte als erforderlich angeben.
In der Anweisung ibm.tolerates aufgeführte Singletonversionen werden nur im Fall eines Versionskonflikts verwendet. Die Reihenfolge der in der Anweisung ibm.tolerates genannten Versionen ist unerheblich. Jede in der Anweisung ibm.tolerates genannte Version kann zur Erfüllung von Abhängigkeitsanforderungen ausgewählt werden.
Die für ein angegebenes Singleton-Feature genannten tolerierten Versionen bzw. Versionen müssen in der Anweisung ibm.tolerates explizit angegeben werden. Verwenden Sie Kommas, um die tolerierten Versionen in der Liste voneinander abzugrenzen. Die Angabe eines Versionsbereichs wird nicht unterstützt.
Beispiel:Subsystem-Content: com.ibm.websphere.appserver.example.featureA-1.1; ibm.tolerates:="1.2"; type="osgi.subsystem.feature", com.ibm.websphere.appserver.example.featureB-1.1; ibm.tolerates:="1.2, 1.4, 1.6"; type="osgi.subsystem.feature"
Anmerkung:Tolerierte Versionen sind nicht transitiv. Auf diese Weise wird verhindert, dass ein Feature, von dem Ihr Feature abhängt, automatisch aufgenommen und so betrachtet wird, als würde es eine höhere Version eines Features unterstützen, ohne dass dies getestet wird.
Beispiel: Das Benutzerfeature featureC-1.1 beinhaltet sipServlet-1.1 im Header "Subsystem-Content" der zugehörigen Manifestdatei. sipServlet-1.1 schließt servlet-3.0 ein und toleriert servlet 3.1. Wenn das Feature featureC-1.1 vor servlet-3.1 geschrieben wurde und anschließend wude servlet-3.1 von dem Feature hinzugefügt und toleriert, das es verwendet hat (sipServlet-1.1), dann sollte die Angabe zur Toleranz von servlet-3.1 durch das Feature featureC-1.1 erfolgen.
Wenn Sie die Datei server.xml so konfigurieren, dass sie die folgenden beiden Features beinhaltet:
Es wird eine Fehlernachricht ähnlich der folgenden angezeigt:<feature>usr:featureC-1.1</feature> // Enthält: sipServlet-1.1 <feature>websocket-1.0</feature> // Dieses Feature erfordert servlet-3.1
CWWKF0033E: Die Singleton-Features servlet-3.0 und servlet-3.1 können nicht gleichzeitig geladen werden. Die konfigurierten Featues usr:featureC-1.1 und websocket-1.0 enthalten mindestens ein Feature, das den Konflikt verursacht. Ihre Konfiguration wird nicht unterstützt. Aktualisieren Sie die Datei server.xml und entfernen Sie die inkompatiblen Features.
Dieser Fehler wird angezeigt, weil das Feature featureC-1.1 servlet-3.1 nicht toleriert und somit servlet-3.0 verwenden muss und websocket-1.0 wiederum servlet-3.0 nicht unterstützt und somit servlet-3.1 verwenden muss.
Dieses Problem wird gelöst, wenn das Feature featureC-1.1 ebenfalls direkt von servlet-3.0 abhängig ist und servlet-3.1 toleriert.
- ibm.zos.extended.attributes - Setzt die erweiterten Attribute
für die zugeordnete Datei auf den angegebenen Wert. Der Wert kann eine beliebige Kombination
der Werte a','l','p' und
's' sein. Übersicht über die Wertoptionen:
- a = von APF berechtigt
- p = vom Programm gesteuert
- s = gemeinsam genutzter Adressraum ("shared")
- l = gemeinsam genutzte Bibliothek ("library")
- ibm.file.encoding - Konvertiert die zugeordnete Datei aus der ASCII-Codierung in den angegebenen Codierungstyp. Die Anweisung ibm.file.encoding kann den Wert "ebcdic" annehmen, wodurch die in ASCII codierte Datei in die EBCDIC-Codierung konvertiert wird.
- 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.
Bei Angabe eines anderen Werts 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
Subsystem-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 Subsystem-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 Subsystem-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 Featuremanifestdatei 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.
Als Wert für productVersion können Sie entweder die exakte Version angeben, wie z. B. 8.5.5.7, oder eine minimale Versionsnummer, die durch die Angabe einer Versionsendung mit einem Pluszeichen (+), wie z. B. 8.5.5.7+, gekennzeichnet ist.
Als Wert für productEdition können Sie entweder eine einzelne Edition oder ein durch Kommas getrennte Liste mit Editionen angeben, die Sie in Anführungszeichen einschließen.
IBM-AppliesTo: com.ibm.websphere.appserver; productVersion=8.5.5.6; productInstallType=Archive; productEdition="BASE,DEVELOPERS,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
![[18.0.0.1 und höher]](../ng_v18001plus.gif)
IBM-Maven-Dependency
IBM-Maven-Dependency: javax.servlet:javax.servlet-api:3.1.0
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