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.

Anmerkung: Die Attribute in der Featuremanifestdatei werden im Format Name=Wert, Anweisungen im Format Name:=Wert angegeben.

Die folgenden Header sind definiert:
Tabelle 1. Header einer Featuremanifestdatei.

In der folgenden Tabelle sind die Header einer Featuremanifestdatei im Liberty-Profil aufgelistet. Die erste Spalte enthält eine Liste der Header, die zweite Spalte enthält die Beschreibungen der Header, und die dritte Spalte gibt an, ob der jeweilige Header erforderlich ist.

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.

Die folgenden Attribute werden unterstützt:
  • 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.
    Dieses Attribut ist optional. Der Standardwert ist false.

    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.
Die folgende Anweisung wird unterstützt:
  • 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.
Beispiel:
Subsystem-SymbolicName: com.ibm.example.feature-1.0; 
    visibility:=public; superseded=true; superseded-by="com.ibm.example.feature-2.0"
Wenn ein Featurename in der Liste "superseded-by" in eckige Klammern [] eingeschlossen ist, wurde dieses Feature vom ersetzenden Feature getrennt. Im folgenden Beispiel wird das Feature appSecurity-1.0, das die Features servlet-3.0 und ldapRegistry-3.0 enthält, durch das Feature appSecurity-2.0 ersetzt, das die Features servlet-3.0 und ldapRegistry-3.0 nicht enthält:
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.
Bewährtes Verfahren: Wenn das Feature in den Entwicklertools angezeigt werden soll, muss es öffentlich (public) sein. Wenn das Feature nur für anerkannte Parteien verfügbar sein soll, muss es geschützt (protected) sein. Wenn das Feature intern ist und Änderungen vorbehalten sind, muss es privat (private) sein.

Subsystem-Content

Dieser Header definiert den Inhalt des Features für die Laufzeitumgebung und für die Installation. Für diesen Header gilt dieselbe Headersyntax wie für die Subsystemspezifikation mit der folgenden Syntax:
Subsystem-Content ::= Inhalt ( ',' Inhalt )*
        content ::= eindeutiger_Name ( ';' Parameter )*
        unique-name ::= eindeutiger_Name (siehe Abschnitt 1.3.2 der OSGi-Kernspezifikation)
Für unique-name wird das Format des Headers Bundle-SymbolicName oder Subsystem-SymbolicName verwendet. Die folgenden Attribute werden unterstützt:
  • 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.
Die folgenden Anweisungen werden unterstützt:
  • 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.
    Bundles können auch so definiert werden, dass sie unmittelbar vor oder unmittelbar nach diesen Phasen gestartet werden, indem _LATE für einen Start nach bzw. _EARLY für einen Start vor der Schlüsselphase hinzugefügt wird. Wenn die Ausführung also unmittelbar nach der Containerphase erfolgen soll, verwenden Sie CONTAINER_LATE. Wenn die Ausführung unmittelbar vor der APPLICATION-Phase erfolgen soll, verwenden Sie APPLICATION_EARLY.
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"
Für AIX-PlattformenFür HP-UNIX-PlattformenFür LINUX-PlattformenFür Solaris-PlattformenFür IBM i-PlattformenLiberty-Repository[8.5.5.4 oder höher]In Version 8.5.5.4 und höher wird folgende Anweisung unterstützt:
  • 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.

Beispiel:
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.

Beispiel:
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.

Beispiel:
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.

Das folgende Attribut wird unterstützt:
  • 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.
Beispiel:
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.

Er hat die folgende Syntax:
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.
Beispiel:
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.

Beispiel:
<?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

Dieser Header gibt die Liberty-Version an, für die dieses Feature gilt. Geben Sie eine durch Kommas getrennte Liste mit Einträgen an, die jeweils das folgende Format haben:
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.

Beispiel:
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.

Beispiel:
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.

Beispiel:
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.

Beispiel:
IBM-License-Information: lafiles/LI

IBM-App-ForceRestart

Dieser Header bewirkt, dass Anwendungen erneut gestartet werden, wenn das Feature in einem aktiven Server installiert oder entfernt wird. Die gültigen Werte für diesen Header sind folgende:
  • 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

Im Folgenden sehen Sie eine Beispieldefinition für das Feature example-1.0. Das Attribut für die allgemeine Sichtbarkeit ermöglicht die direkte Angabe dieses Features in den Serverkonfigurationsdateien (server.xml). Es wird auch in die Dropdown-Liste der Features aufgenommen, die in der Ansicht Serverkonfiguration der Entwicklertools angezeigt werden und kann auch in Features in anderen Produkterweiterungen aufgenommen werden. Wenn dieses Feature in der Produkterweiterung usr einer Laufzeitinstallation installiert wird, kann es durch den Einschluss des folgenden Codes in die Datei server.xml in einem Server konfiguriert werden:
<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

Symbol das den Typ des Artikels anzeigt. Referenzartikel

Nutzungsbedingungen für Information Center | Feedback


Symbol für Zeitmarke Letzte Aktualisierung: 25.08.2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=rwlp_feat_definition
Dateiname: rwlp_feat_definition.html