Unterstützung der externen Funktionen und Ressourcen von Liberty

Externe Funktionen und Ressourcen von Liberty können direkt verwendet werden und sind im nächsten Release auf jeden Fall verfügbar. Interne oder nebensächliche Aspekte von Liberty können sich ändern, wenn Sie Servicepakete anwenden oder ein Upgrade auf ein künftiges Release durchführen.

Welche Ressourcen können direkt in Liberty verwendet werden und sind auf jeden Fall im nächsten Release enthalten?

Die folgenden Ressourcen können direkt verwendet werden und sind auch im nächsten Release verfügbar:
  • Die über den Inhalt der JAR-Dateien in den Verzeichnissen ${wlp.install.dir}/dev definierten APIs (Anwendungsprogrammierschnittstellen) und SPIs (Systemprogrammierschnittstellen).
    • Der Anwendungsklassenlader hat Zugriff auf die API, die von den Features in Ihrer Serverkonfiguration bereitgestellt wird. Produkterweiterungsfeatures haben Zugriff auf alle APIs und SPIs, die von den Features in Ihrer Serverkonfiguration bereitgestellt werden.
    • Kompilieren Sie Ihren Code anhand der JAR-Dateien im Verzeichnis ${wlp.install.dir}/dev. Die in den Verzeichnissen unter ${wlp.install.dir}/dev bereitgestellten JAR-Dateien sind nur für die Kompilierung von Anwendungen und Features vorgesehen. Für diese Dateien gibt es keine Laufzeitunterstützung. Verwenden Sie diese JAR-Dateien nicht in Anwendungen, in Bibliotheken oder für Tests.
  • Die Serverkonfiguration, einschließlich Features mit Sichtbarkeit vom Typ public oder protected. In der Datei server.xml und darin enthaltenen Dateien können öffentliche Features und Konfigurationselemente definiert werden. In Ihren eigenen Features können Sie geschützte Features angeben.
  • Befehle, Scripts und Archive im Verzeichnis ${wlp.install.dir}/bin und in zugehörigen Unterverzeichnissen.
  • Clientdienstprogramme im Verzeichnis ${wlp.install.dir}/clients und in zugehörigen Unterverzeichnissen.

Wo sollten Abhängigkeiten vermieden werden?

Erstellen Sie keine Abhängigkeiten von nebensächlichen Aspekten des Produkts. Die Erstellung von Abhängigkeiten von nebensächlichen Aspekten kann sich nachteilig auf das Produkt auswirken, wenn Sie Servicepakete oder Upgrades auf künftige Releases anwenden. Beispiele für interne Produktressourcen und -funktionen, auf die sich nicht verlassen sollten, sind u. a. die folgenden Szenarien:
  • Namen von JAR-Dateien mit Produktbinärdateien, z. B. im Verzeichnis ${wlp.install.dir}/dev. Kompilieren Sie Ihren Code unter Verwendung dieser JAR-Dateien mit den Tools oder mit der Option javac -extdirs.
    Wenn Sie Apache Ant verwenden, um Ihren Code zu kompilieren, verwenden Sie Platzhalterzeichen, um Abhängigkeiten von einer bestimmten JAR-Version zu vermeiden. Beispiel:
    <fileset dir="${wlp.install.dir}/dev/api/spec" includes="com.ibm.ws.javaee.servlet.3.0_*.jar"/>
    Alternativ können Sie den Befehl featureManager classpath verwenden, um einen Klassenpfad für eine bestimmte Gruppe von Features zu generieren. Weitere Informationen finden Sie im Artikel Befehl "featureManager".
  • Direkte Verwendung der Produktbinärdateien im Verzeichnis ${wlp.install.dir}/lib. Die einzigen JAR-Dateien, die direkt aufgerufen werden können, befinden sich im Verzeichnis ${wlp.install.dir}/bin/tools.
  • Nachrichten, die vom Server zur Laufzeit ausgegeben werden. Änderungen an Nachrichtentexten und -einfügungen bei Service- und Versionsupgrades sind vorbehalten. Das Produkt wird im Rahmen der praktischen Durchführbarkeit Nachrichten-IDs, die bei bestimmten Operationsvorgängen ausgegeben werden, konsistent verwenden. Dies kann jedoch nicht garantiert werden, da sich die zugrunde liegenden Implementierungen ändern könnten.
  • Layout der Produktinstallation mit Ausnahme der Verzeichnisse ${wlp.install.dir}/bin und ${wlp.install.dir}/dev.
  • Beispiele und Vorlagendateien im Verzeichnis ${wlp.install.dir}/templates. Diese Dateien können geändert werden, wenn Sie Services auf Ihre Installation anwenden.
  • Private Java™-Pakete oder Java-Pakete anderer Anbieter, die nicht explizit als APIs bereitgestellt werden. Diese sind für den Anwendungsklassenlader zur Laufzeit nicht sichtbar.

Was kann beim Anwenden von Servicepaketen oder beim Durchführen eines Upgrades geändert werden?

Der Inhalt der folgenden Verzeichnisse und deren Unterverzeichnisse kann beim Anwenden eines Servicepakets oder Durchführen eines Upgrades geändert werden. Nehmen Sie keine eigenen Änderungen an den Dateien an diesen Positionen vor, da diese durch Produktwartungen oder -upgrades überschrieben werden können:
  • ${wlp.install.dir}/bin
  • ${wlp.install.dir}/clients
  • ${wlp.install.dir}/dev
  • ${wlp.install.dir}/java
  • ${wlp.install.dir}/lib
  • ${wlp.install.dir}/templates
Es werden keine Änderungen am Inhalt der folgenden Verzeichnisse vorgenommen. Diese Verzeichnisse enthalten Ihre Dateien, die beim Anwenden eines Servicepakets oder beim Durchführen eines Upgrades nicht geändert werden:
  • ${wlp.install.dir}/etc (In diesem Verzeichnis haben Sie möglicherweise eine Datei server.env oder jvm.options hinzugefügt.)
  • ${wlp.install.dir}/usr (Die Standardposition für Benutzerkonfigurationen und -anwendungen.)
  • Alle vom Standardverzeichnis abweichenden Verzeichnisse, die Sie mit der Umgebungsvariablen WLP_USER_DIR festlegen.

Für IBM i-PlattformenEs gibt eine Ausnahme von der Richtlinie, dass keine Änderungen am Inhalt von ${wlp.install.dir}/etc vorgenommen werden. Die Datei ${wlp.install.dir}/etc/default.env wird erstellt, wenn Sie Liberty mit Installation Manager auf Plattformen mit IBM® iSeries installieren. Diese Datei wird auch bei Archiv- und Job-Manager-Installationen vom Befehl iAdmin POSTINSTALL erstellt bzw. ersetzt. Der Befehl iAdmin befindet sich im Verzeichnis ${wlp.install.dir}/lib/native/os400/bin. Nähere Informationen hierzu finden Sie unter Befehl "iAdmin".

APIs anderer Anbieter können sich mit der Zeit ohne Berücksichtigung der Abwärtskompatibilität ändern. Es handelt sich dabei um Java-Pakete, die als Teil der Implementierung von Features betrachtet werden, die in Open-Source-Communitys entwickelt werden und im Lieferumfang von Liberty enthalten sind. APIs anderer Anbieter sind für Anwendungen standardmäßig nicht sichtbar. Java EE-Anwendungen mit einer Klassenladeprogrammkonfiguration, die den Zugriff Dritter explizit zulässt, sind für diese Pakete im Anwendungsklassenlader sichtbar und OSGi-Anwendungen müssen die Pakete explizit importieren. Berücksichtigen Sie die Auswirkungen inkompatibler Änderungen, bevor Sie sich für die Verwendung von APIs anderer Anbieter entscheiden.


Symbol das den Typ des Artikels anzeigt. Referenzartikel



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