Produkterweiterung

Sie können die Liberty-Funktionalität durch Schreiben von Produkterweiterungen ergänzen.

Sie können eigene Liberty-Features schreiben und in einem vorhandenen Liberty-Server installieren oder die Features für die Übermittlung an Ihre Benutzer packen.

Liberty stellt verschiedene Systemprogrammierschnittstellen (SPIs) bereit, die Sie verwenden können, um die Laufzeitumgebung zu erweitern. Sie können auch erweiterte Features verwenden, wie z. B. die programmgesteuerte Ausführung des Liberty-Servers über Ihre Java™-Anwendungen.

Produkterweiterung

Eine Produkterweiterung ist ein Verzeichnis auf einem Datenträger, das wie das Liberty-Installationsverzeichnis, ${wlp.install.dir}, strukturiert ist. Sie wird in der Liberty-Installation über die Datei Name_der_Erweiterung.properties im Verzeichnis ${wlp.install.dir}/etc/extensions definiert. Der Inhalt des Produkterweiterungsverzeichnisses wird dann zur Erweiterung von Liberty verwendet. Es können mehrere Produkterweiterungen gleichzeitig installiert werden, allerdings müssen sie dann eindeutige Namen haben. Dies wird durch die Benennung der Eigenschaftendateien sichergestellt. Das Standardverzeichnis für Produkterweiterungen, ${wlp.user.dir}/extension, erfordert keine Eigenschaftendatei. Der Inhalt in diesem Verzeichnis wird automatisch erkannt und ist der Laufzeitumgebung als Produkterweiterung "usr" bekannt.

Produkterweiterungen enthalten normalerweise ein oder mehrere Liberty-Features. Sie können aber auch jeden beliebigen Inhalt zur Erweiterung der Liberty-Umgebung haben, z. B. Scripts oder Ressourcen.

Bewährtes Verfahren: Installieren Sie Ihre Produkterweiterungen in Verzeichnissen, die nicht von Aktualisierungen der Liberty-Umgebung betroffen sind. Weitere Informationen finden Sie unter Was kann beim Anwenden von Servicepaketen oder beim Durchführen eines Upgrades geändert werden?.
Abbildung 1. Diagramm mit einer Liberty-Installation mit den Features Supergui und App Services
Die Produkterweiterungsdatei hat die folgenden Eigenschaften:
com.ibm.websphere.productId=Ihre_Produkt_ID
com.ibm.websphere.productInstall=Absoluter_oder_relativer_Pfad
Anmerkung: Wenn Sie einen relativen Pfad angeben, muss dieser ein Peer des ${wlp.install.dir}-Werts sein.
Beispiel:
com.ibm.websphere.productId=org.acme.supergui
com.ibm.websphere.productInstall=supergui/wlp-ext

Feature

Ein Liberty-Feature besteht aus einer Definitionsdatei (Featuremanifest) und einer Gruppe von OSGi-Bundles, die Klassen und Services für eine bestimmte Funktionalität in der Liberty-Laufzeitumgebung bereitstellen.

Szenarien für die Verwendung eines Liberty-Features anstelle einer normalen Anwendung

Es gibt eine Reihe von Szenarien, in denen sich die Implementierung einer Funktion als Liberty-Feature anstelle einer Anwendung anbietet. In der folgenden Liste sind einige Vorteile der Verwendung eines Features beschrieben:
  • Features werden über die Feature-Manager-Konfiguration gesteuert, sodass sie vom Management der Benutzeranwendungen getrennt sind.
  • Der Feature-Code kann auf die Liberty-SPI zugreifen, was eine tiefere Integration in die Laufzeitumgebung ermöglicht.
  • Die Features können benutzerdefinierte Konfigurationseinstellungen aus der Datei server.xml übernehmen und ihre Konfigurationseinstellungen in den Entwicklungstools bereitstellen, ohne dass die Tools geändert werden müssen.
  • Die Features können Klassen und Services ohne großen Aufwand einander und Benutzeranwendungen bereitstellen.
  • Features können sehr schlank sein und haben keine Abhängigkeiten von Anwendungscontainern.
  • Features können verwendet werden, um ein bestimmtes Programmiermodell zu erweitern. Beispielsweise kann ein Benutzerfeature Unterstützung für angepasste Blueprint-Namespace-Handler oder Blueprint-Annotationen zum OSGi-Anwendungsprogrammiermodell hinzufügen.
Anmerkung: Features sind gewöhnlich nicht direkt in andere Anwendungsserver portierbar. Wenn die Portierbarkeit wichtig ist, müssen Sie spezifikationskonforme Anwendungen verwenden.

Feature im Server verwenden

Wenn Sie ein benutzerdefiniertes Feature im Liberty-Server verwenden möchten, müssen Sie das Feature in einem Produkterweiterungsverzeichnis installieren. Dabei kann es sich um das vordefinierte Verzeichnis für benutzerspezifische Produkterweiterungen oder eine Erweiterung handeln, die sich außerhalb des Liberty-Installationsverzeichnisses befindet. Anschließend können Sie den Featurenamen der Serverkonfiguration hinzufügen.

Das benutzerspezifische Produkterweiterungsverzeichnis ist ein vordefiniertes Verzeichnis, in dem der Server nach zusätzlichen Features sucht. Sie müssen die Featuredefinitionsdatei mit der Erweiterung .mf in das Verzeichnis ${wlp.user.dir}/extension/lib/features und die Bundledateien mit der Erweiterung .jar in das Verzeichnis ${wlp.user.dir}/extension/lib kopieren.

Benutzerdefinierte Features werden der Serverkonfiguration wie Produktfeatures hinzugefügt. Zur Vermeidung von Namenskollisionen mit Features anderer Anbieter muss den Features, die zu einer Produkterweiterung gehören, der Name der Erweiterung vorangestellt werden. Für Features im Verzeichnis usr/extension/lib ist das Standardpräfix usr:.

Wenn Sie beispielsweise ein Feature mit dem Namen simple-1.0 im Verzeichnis ${wlp.user.dir}/extension/lib installiert haben, müssen Sie das Feature in der Datei server.xml wie folgt konfigurieren:
<featureManager>
    <feature>usr:simple-1.0</feature>
</featureManager>
Wenn Sie ein Feature mit dem Namen myFeature in Ihrem eigenen Verzeichnis installiert und eine Produkterweiterung in der Datei ${wlp.install.dir}/etc/extensions/myExt.properties definiert haben, müssen Sie das Feature in der Datei server.xml wie folgt konfigurieren:
<featureManager>
    <feature>myExt:myFeature</feature>
</featureManager>

Wenn Sie den Server starten, wird das Feature vom Feature-Manager erkannt, und die Bundles werden im OSGi-Framework installiert und gestartet.

Weitere Informationen hierzu finden Sie in den Abschnitten Liberty-Features hinzufügen und entfernen und Featureverwaltung.

Programmgesteuerte Verwendung eines Features in Anwendungen

Features können Anwendungen Klassen und Services bereitstellen.

Wenn Sie Java-Klassen zur Verwendung durch Anwendungen bereitstellen möchten, müssen Sie die Klassenpakete im Header IBM-API-Package des Featuremanifests auflisten. Durch die Auflistung der Klassenpakete im Header IBM-API-Package werden die Klassen für die Anwendungsklassenlader sichtbar. Die Sichtbarkeit von API-Paketen kann über den API-Sichtbarkeitstyp gesteuert werden. Weitere Informationen finden Sie unter API- und SPI-Pakete für ein Liberty-Featureprojekt angeben.

Damit Services von OSGi-Anwendungen verwendet werden können, müssen Sie sie im Header IBM-API-Service des Featuremanifests auflisten. Ein Feature stellt OSGi-Services bereit, sodass Sie in Ihren Anwendungen programmgesteuert auf diese Services verweisen können.

Services müssen in der OSGi-Service-Registry (SR) registriert werden, damit sie von Anwendungen (oder anderen Features) gefunden werden können. OSGi-Anwendungen und andere Features können ein Direkt-Lookup über die Service-Registy durchführen oder Funktionen wie Blueprint oder OSGi Declarative Services für die Injektion ihrer Serviceabhängigkeiten verwenden. Java EE-Anwendungen suchen Services wahrscheinlich eher über JNDI. In Liberty gibt es einen Verbund von Service-Registry und JNDI, der es Java EE-Anwendungen ermöglicht, JNDI für die Suche von Services in der Service-Registry zu verwenden. Weitere Informationen finden Sie unter Mit der OSGi-Service-Registry arbeiten.

Feature als Webanwendung bereitstellen

Wenn Sie ein Liberty-Feature als Webanwendung bereitstellen möchten, können Sie die OSGi-Bundles im Feature als Webanwendungsbundles (WABs) veröffentlichen. Neben den OSGi-Headern, die ein Bundle erfordert, können Sie den Kontextpfad der Webanwendung mit dem Header Web-ContextPath angeben.

Beispiel:

Web-ContextPath: myWABapp
Bundle-ClassPath: WEB-INF/classes

Konfigurationsinjektion und -verarbeitung

Einer der bedeutenden Vorteile der Verwendung von Features ist der, dass die Features ohne großen Aufwand vom Benutzer in der Datei server.xml (und eingeschlossenen Dateien) konfiguriert werden können. Die Konfigurationsdateien werden vom Liberty-Kernel überwacht und geparst, und die daraus resultierenden Eigenschaftensätze können bei jeder Änderung in die entsprechende Komponente eingefügt werden.

Die Liberty-Konfiguration wird vom OSGi-Configuration-Admin-Service im Kernel verwaltet und kann entsprechend dieser Spezifikation aufgerufen werden. Die Konfigurationseigenschaftensätze werden mit einer persistent definierten ID (PID) angegeben, die verwendet wird, um das Element in der Datei server.xml der Komponente zuzuordnen, die sich für den Erhalt der Eigenschaften registriert.

Wenn Sie Ihr Feature beim Configuration-Admin-Service beispielsweise mit der PID com.acme.console registrieren, kann der Benutzer die folgende Konfiguration in der Datei server.xml angeben:
<com.acme.console color="blue" size="17"/>
In diesem Fall übernimmt Ihr Feature die folgenden Eigenschaften:
  • color="blue"
  • size="17"

Optional können Sie in OSGI-Metatypdeskriptoren Metadaten angeben, die Ihre Konfigurationseigenschaften beschreiben. Die Verwendung von Deskriptoren bewirkt, dass Ihre Konfigurationsmetadaten in das Konfigurationsschema eingeschlossen werden, das von Liberty generiert und von den Entwicklertools verwendet wird, sodass Ihre Konfigurationseigenschaften Anwendungsentwicklern automatisch angezeigt werden, wenn diese den Server konfigurieren.

Weitere Informationen zum Erhalt und zur Beschreibung von Konfigurationseigenschaften finden Sie unter Service für den Empfang von Konfigurationsdaten aktivieren.

Declarative Services in Liberty

Größere und komplexere Features profitieren häufig von der Verwendung von OSGi Declarative Services (DS), damit ein Feature aus mehreren Services zusammengesetzt und die Injektion von Abhängigkeiten und Konfigurationseigenschaften verwaltet werden kann. Die Verwendung von DS lässt eine verzögerte Aktivierung von Services (hierbei wird das Laden von Java-Klassen bis zur tatsächlichen Verwendung des Service verzögert) und die Festlegung einer Reihenfolge für die Aktivierung der Services basierend auf Abhängigkeiten zu. Die meisten Features im Liberty-Produkt werden von DS verwaltet.

Weitere Informationen finden Sie unter Erweiterte Features mit OSGi Declarative Services erstellen.


Symbol das den Typ des Artikels anzeigt. Konzeptartikel



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