Klassen für Java EE-Clientanwendungen laden

Wenn Sie den Java EE-Anwendungsclient (Java™ Platform, Enterprise Edition) ausführen, wird eine Hierarchie von Klassenladern für das Laden der von Ihrer Anwendung verwendeten Klassen erstellt.

Die folgende Liste beschreibt die Hierarchie der Klassenlader:
  • Die Laufzeitumgebung von Application Client for WebSphere Application Server (Application Client) setzt diesen Wert auf die Umgebungsvariable WAS_LOGGING.
  • [AIX Solaris HP-UX Linux Windows][z/OS]Der Klassenlader für Erweiterungen ist dem Bootstrapklassenlader untergeordnet. Dieser Klassenlader enthält JAR-Dateien im Verzeichnis java/jre/lib/ext oder JAR-Dateien, die der Parameter -Djava.ext.dirs im Java-Befehl definiert. Die Clientlaufzeitumgebung von Application Client setzt die Parameter -Djava.ext.dirs nicht. Es werden die JAR-Dateien im Verzeichnis java/jre/lib/ext verwendet.
  • [IBM i]Der Klassenlader für Erweiterungen ist dem Bootstrapklassenlader untergeordnet. Dieser Klassenlader enthält JAR-Dateien im Verzeichnis Stammverzeichnis_des_Anwendungsservers /java/ext, im Verzeichnis "java_home/lib/ext" oder "java_home/jre/lib/ext" und im Verzeichnis "/QIBM/UserData/Java400/ext". Das Verzeichnis Stammverzeichnis_des_Anwendungsservers ist der Produktinstallationspfad. Das Verzeichnis "java_home" ist der Installationspfad für die Java-Dateien.
    [IBM i]Achtung: Der Parameter "java_home" kann einen von drei Werten annehmen, je nachdem, welche JVM (Java Virtual Machine) aktiviert ist. Dabei handelt es sich um die folgenden drei Werte:
    • /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit (Java SE 6 32-Bit)
    • /QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit (Java SE 6 64-Bit)
  • Der Systemklassenlader enthält JAR-Dateien und Klassen, die der Parameter -classpath im Java-Befehl definiert. Die Laufzeitumgebung von Application Client setzt diesen Parameter auf die Umgebungsvariable WAS_CLASSPATH.
  • Der WebSphere-Klassenlader lädt die Laufzeitumgebung von Application Client und alle Klassen, die in den Benutzerverzeichnissen von Application Client gespeichert sind. Die von diesem Klassenlader verwendeten Verzeichnisse werden mit der Umgebungsvariablen WAS_EXT_DIRS definiert. Die Umgebungsvariablen WAS_BOOTCLASSPATH, WAS_CLASSPATH und WAS_EXT_DIRS werden für Installationen von WebSphere Application Server im Script Stammverzeichnis_des_Anwendungsservers/bin/setupCmdLine und für Clientinstallationen im Script Stammverzeichnis_des_Anwendungsservers/bin/setupClient festgelegt.

Bei der Initialisierung der Laufzeit des Java EE-Anwendungsclients werden zusätzliche Klassenlader als untergeordnete Klassenlader des WebSphere-Klassenladers erstellt. Wenn Ihre Clientanwendung verschiedene Ressourcen, z. B. JDBC-API (Java DataBase Connectivity), JMS-API (Java Message Service) oder URL (Uniform Resource Locator), verwendet, wird jeweils ein eigener Klassenlader für das Laden dieser Ressourcen erstellt. Schließlich stellt die Application-Client-Laufzeit den Klassenlader von WebSphere so ein, dass er die Klassen aus der EAR-Datei lädt. Die Manifestdatei der Client-JAR-Datei wird hierfür mehrfach verarbeitet. Der von der Umgebungsvariablen CLASSPATH definierte Systemklassenpfad, wird nicht verwendet und gehört nicht zur Hierarchie der Klassenlader.

Um Ihre Clientanwendung korrekt zu packen, müssen Sie wissen, welcher Klassenlader Ihre Klassen lädt. Wenn der Java-Code eine Klasse lädt, wird der zum Laden dieser Klasse verwendete Klassenlader Java zugeordnet. Alle Klassen, die anschließend von dieser Klasse geladen werden, verwenden diesen Klassenlader oder einen seiner übergeordneten Klassenlader, jedoch keinen der untergeordneten Klassenlader.

In einigen Fällen kann die Application-Client-Laufzeitumgebung erkennen, wenn Ihre Clientanwendung von einem anderen Klassenlader geladen wird als dem, der dafür von der Application-Client-Laufzeitumgebung erstellt wurde. In diesem Fall wird die folgende Nachricht angezeigt:
WSCL0205W: Zum Laden von {0} wurde ein ungültiger Klassenlader verwendet
Diese Nachricht wird angezeigt, wenn die Klasse Ihrer Clientanwendung von einem der übergeordneten Klassenlader in der Hierarchie geladen wird. Dies kommt in der Regel vor, wenn in der EAR-Datei und auf dem Festplattenlaufwerk dieselben Klassen vorhanden sind. Wenn einer der übergeordneten Klassenlader eine Klasse findet, lädt er diese, bevor der Klassenlader der Application-Client-Laufzeitumgebung dies tun kann. In einigen Fällen hat dies keine Auswirkungen auf die Funktionsweise der Clientanwendung. In den meisten Fällen erhalten Sie jedoch Ausnahmen des Typs "Klasse nicht gefunden".

Felder des Klassenpfads konfigurieren

Beim Packen Ihrer Java EE-Clientanwendung müssen Sie verschiedene Felder des Klassenpfades konfigurieren. Im Idealfall sollten Sie alle Komponenten, die von Ihrer Anwendung benötigt werden, in die EAR-Datei packen. Dies ist die einfachste Methode zur Verteilung Ihrer Java EE-Clientanwendung auf Ihre Clients. Jedoch sollten Sie keine Ressourcen wie JDBC-APIs, JMS-APIs oder URLs packen. Für diese Ressourcen sollten Sie Referenzen auf den Klassenpfad verwenden, um auf diese Klassen auf der Festplatte zuzugreifen. Es sind eventuell noch andere Klassen auf Ihren Clientmaschinen installiert, die Sie nicht erneut verteilen müssen. In diesem Fall sollten Sie ebenfalls Referenzen auf den Klassenpfad verwenden, um auf die Klassen auf der Festplatte zuzugreifen (siehe Beschreibung weiter unten).

Auf Klassen in der EAR-Datei verweisen

Java EE-Anwendungen des WebSphere-Produkts verwenden nicht den Systemklassenpfad. Verwenden Sie den Klassenpfadeintrag MANIFEST, um auf andere JARs in der EAR-Datei zu verweisen. Konfigurieren Sie diese Werte mit einem Assembliertool. Wenn Ihre Clientanwendung auf den Pfad der EJB-JAR-Datei zugreifen muss, fügen Sie den Klassenpfad des Anwendungsclients den Namen des implementierten Enterprise-Bean-Moduls hinzu. Das Format des Klassenpfadfeldes ist für die verschiedenen Module (Anwendungsclient, EJB, Web) dasselbe:
  • Die Werte müssen auf JAR- und Klassendateien verweisen, die in der EAR-Datei enthalten sind.
  • Die Werte müssen relativ zum Stammverzeichnis der EAR-Datei angegeben werden.
  • Die Werte dürfen nicht auf absolute Pfade in den Dateisystemen verweisen.
  • Bei der Angabe mehrerer Werte müssen diese durch Leerzeichen, nicht durch Doppelpunkte oder Semikolons getrennt werden.
Achtung: Diese Java-Methode unterstützt die plattformunabhängige Ausführung von Anwendungen.

In der Regel werden Module (JAR-Dateien) zum Stammverzeichnis der EAR-Datei hinzugefügt. In diesem Fall müssen Sie im Feld "Klassenpfad" nur den Namen des Moduls (JAR-Datei) angeben. Wenn Sie ein Modul mit einem Pfad hinzufügen möchten, müssen Sie den Pfad relativ zum Stammverzeichnis der EAR-Datei angeben.

Für Verweise auf Klassendateien müssen Sie das Verzeichnis relativ zum Stammverzeichnis der EAR-Datei angeben. Mit einem Assembliertool können Sie der EAR-Datei einzelne Klassendateien hinzufügen. Es wird empfohlen, diese zusätzlichen Klassendateien in eine JAR-Datei zu packen. Fügen Sie anschließend diese JAR-Datei dem Feld "Klassenpfad" des Moduls hinzu. Wenn Sie Klassendateien dem Stammverzeichnis der EAR-Datei hinzufügen, geben Sie im Feld "Klassenpfad" des Moduls ./ ein.

Sehen Sie sich die Verzeichnisstruktur des folgenden Beispiels an, in dem die Datei "meinAnw.ear" eine JAR-Datei für den Anwendungsclient mit dem Namen meinClient.jar und ein EJB-Modul mit dem Namen meineBeans.jar enthält. Weitere Klassen sind in den Dateien class1.jar und utility/class2.zip enthalten. Eine Klassendatei mit dem Namen xyz.class ist nicht in einer JAR-Datei gepackt, sondern befindet sich im Stammverzeichnis der EAR-Datei. Geben Sie ./ mybeans.jar utility/class2.zip class1.jar als Wert für die Eigenschaft "Klassenpfad" an. Die Suchreihenfolge sieht wie folgt aus: meineAnw.ear/meinClient.jar meineAnw.ear/xyz.class meineAnw.ear/meineBeans.jar meineAnw.ear/utility/class2.zip meineAnw.ear/class1.jar

Auf nicht in der EAR-Datei enthaltene Klassen verweisen

Verwenden Sie den Parameter -CCclasspath von launchClient. Dieser Parameter wird zur Laufzeit angegeben und akzeptiert plattformspezifische Klassenpfadwerte, was bedeutet, dass mehrere Werte durch Semikolons oder Doppelpunkte getrennt werden. Client und Server sind einander in dieser Hinsicht ähnlich.

Ressourcenklassenpfade

Wenn Sie Ressourcen, die von Ihrer Clientanwendung verwendet werden, mit Application Client Resource Configuration Tool[z/OS] (ACRCT) oder mit dem Scripting-Tool ACRCT unter z/OS konfigurieren, können Sie die von den Ressourcen benötigten Klassenpfade angeben. Verwendet Ihre Anwendung beispielsweise JDBC für eine DB2-Datenbank, fügen Sie im Feld "Klassenpfad" des Datenbank-Provider die Datei db2java.zip hinzu. Diese Klassenpfadwerte sind plattformspezifisch und erfordern Semikolons oder Doppelpunkte als Trennzeichen zwischen Werten.

Wenn Sie in WebSphere Application Server den JDBC-Provider IBM® Developer Kit for i5/OS den Java verwenden, um auf DB2/400 zuzugreifen, müssen Sie die Datei db2_classes.jar in den Klassenpfad aufnehmen. Wenn Sie jedoch den den JDBC-Provider IBM Toolbox for Java verwenden, geben Sie den Verzeichnispfad der Datei jt400.jar an.

API "launchClient" verwenden

Wenn Sie den Befehl launchClient verwenden, wird die WebSphere-Klassenladerhierarchie für Sie erstellt. Verwenden Sie jedoch die API launchClient, müssen Sie diese Konfiguration selbst vornehmen. Kopieren Sie den Shell-Befehl launchClient beim Definieren der Java-Systembefehle.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



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