Klassenlader
Klassenladeprogramme suchen und laden Klassendateien. Mit Klassenladerprogrammen (oder kurz Klassenladern) können Anwendungen, die in Servern implementiert sind, auf Repositorys mit verfügbaren Klassen und Ressourcen zugreifen. Anwendungsentwickler und Anwendungsimplementierer (Deployer) müssen die Position der Klassen- und Ressourcendateien und die für den Zugriff auf diese Dateien verwendeten Klassenlader kennen, um die Dateien den implementierten Anwendungen bereitstellen zu können.
Weitere Informationen zu Klassenladern in WebSphere Application Server finden Sie in den folgenden Abschnitten:
- Verwendete Klassenlader und Reihenfolge der Klassenlader
- Isolationsrichtlinien für Klassenlader
- Modi für Klassenlader
- OSGi class loader model
Verwendete Klassenlader und Reihenfolge der Klassenlader
Die Laufzeitumgebung des Produkts verwendet in der angegebenen Reihenfolge die folgenden Klassenlader zum Suchen und Laden neuer Klassen für eine Anwendung:
- Die von der JVM erstellten Klassenlader für Bootstrap, Erweiterungen und Klassenpfad.
Der Bootstrapklassenlader verwendet den Bootklassenpfad (normalerweise Klassen jre/lib), um Klassen zu suchen und zu laden. Der Klassenlader für Erweiterungen verwendet die Systemeigenschaft java.ext.dirs (normalerweise jre/lib/ext), um Klassen zu finden und zu laden. Der Klassenlader für Klassenpfade verwendet die Umgebungsvariable CLASSPATH, um Klassen zu suchen und zu laden.
- Ein Klassenlader für WebSphere-Erweiterungen.
Der Klassenlader für Erweiterungen von WebSphere Application Server lädt zur Laufzeit die benötigten WAS-Klassen. WebSphere Application Server-Klassen werden als Satz von OSGi-Bundles bereitgestellt. Jedes Bundle wird von einem eigenen Klassenlader innerhalb eines Netzes von OSGi-Klassenladern geladen. Der Erweiterungsklassenlader delegiert an einen Gateway-Klassenlader, um Klassen aus diesem OSGi-Klassenladernetz zu laden. Aus dem OSGi-Klassenladernetz exportierte Pakete sind für Anwendungen über das Gateway sichtbar. Details hierzu finden Sie unter OSGi class loader model.
Fehler vermeiden: Die Java EE-APIs werden in den Bundles des Typs javax.j2ee.*.jar bereitgestellt, die innerhalb des OSGi-Klassenladernetzes geladen und für Anwendungen über das Gateway sichtbar gemacht werden. Da in OSGi-Bundles implementierte Klassen nicht für JVM-Klassenlader sichtbar sind, dürfen Sie die Umgebungsvariable CLASSPATH oder die Systemeigenschaften java.ext.dirs und java.lang.classpath nicht verwenden, um Pfade oder Bibliotheken anzugeben, die sich auf die Java EE-APIs stützen. Verwenden Sie CLASSPATH, java.ext.dirs und java.lang.classpath auch nicht, um Pfade zu Anwendungsbibliotheken anzugeben, weil diese Bibliotheken möglicherweise Verbindungsfehler oder unerwartetes Serververhalten verursachen.gotcha
Der Klassenlader für WebSphere-Erweiterungen verwendet die Systemeigenschaft ws.ext.dirs zum Ermitteln des Pfades, der zum Laden der Klassen und Ressourcen, die nicht in OSGi-Bundles enthalten sind, verwendet wird. Jedes Verzeichnis im Klassenpfad ws.ext.dirs und jede JAR-Datei oder komprimierte Datei in diesen Verzeichnissen wird dem Klassenpfad hinzugefügt, der von diesem Klassenlader verwendet wird.
Der Klassenlader für WebSphere-Erweiterungen lädt auch Ressourcenproviderklassen in einen Server, wenn ein auf dem Server installiertes Anwendungsmodul sich auf eine Ressource bezieht, die dem Provider zugeordnet ist, und wenn der Provider den Verzeichnisnamen der Ressourcentreiber angibt.
- Ein oder mehrere Klassenlader für Anwendungsmodule, die Elemente der im Server ausgeführten
Unternehmensanwendungen laden.
Die Anwendungselemente können Webmodule, EJB-Module, Ressourcenadapterarchive (RAR-Dateien) und abhängige JAR-Dateien sein. Die Klassenlader für Anwendungen befolgen die Java EE-Regeln für das Laden von Klassen, um Klassen und JAR-Dateien aus einer Unternehmensanwendung zu laden. Das Produkt gibt Ihnen die Möglichkeit, einer Anwendung gemeinsam genutzte Bibliotheken zuzuordnen.
- Null oder mehrere Klassenlader für Webmodule
Standardmäßig laden die Klassenlader für Webmodule die Inhalte der Verzeichnisse WEB-INF/classes und WEB-INF/lib. Die Klassenlader für Webmodule sind untergeordnete Elemente der Klassenlader für Anwendungen. Sie können festlegen, dass anstelle des Klassenladers für Webmodule ein Klassenlader für Anwendungen den Inhalt eines Webmoduls lädt.

Jeder Klassenlader ist ein Kind des übergeordneten Klassenladers. Das heißt, die Klassenlader für Anwendungsmodule sind dem Klassenlader für WebSphere-Erweiterungen untergeordnet, und dieser ist wiederum dem Java-Klassenlader für Klassenpfade untergeordnet. Immer wenn Klassen geladen müssen, delegiert der Klassenlader normalerweise die Anforderung an seinen übergeordneten Klassenlader. Wenn keiner der übergeordneten Klassenlader die Klasse findet, versucht der ursprüngliche Klassenlader die Klasse zu laden. Anforderungen können nur an einen übergeordneten Klassenlader übertragen werden, nicht an einen untergeordneten. Wenn der Klassenlader für WebSphere-Erweiterungen aufgefordert wird, eine Klasse in einem Java EE-Modul zu finden, kann er sich nicht an den Klassenlader für Anwendungsmodule wenden, um die Klasse zu suchen, und es wird eine Ausnahme ClassNotFoundException ausgelöst. Sobald eine Klasse vom Klassenlader geladen wurde, verwenden alle neuen Klassen, die er zu laden versucht, wieder denselben Klassenlader, oder Sie gehen in der Präzedenzliste nach oben, bis die Klasse gefunden wird.
Isolationsrichtlinien für Klassenlader
Anzahl und Funktion der Klassenlader für Anwendungsmodule richten sich nach den in der Serverkonfiguration definierten Richtlinien für Klassenlader. Klassenlader bieten viele Optionen zum Isolieren von Anwendungen und Modulen, damit verschiedene Paketschemata für Anwendungen auf einem Anwendungsserver ausgeführt werden können.
Zwei Richtlinien für Klassenlader steuern die Isolation von Anwendungen und Modulen:
Richtlinie für Klassenlader | Beschreibung |
---|---|
Anwendung | Klassenlader für Anwendungen laden EJB-Module, abhängige JAR-Dateien, integrierte Ressourcenadapter und anwendungsbezogene gemeinsam genutzte Bibliotheken. Je nach Richtlinie für die Klassenlader für Anwendungen kann der Klassenlader einer Anwendung von mehreren Anwendungen gemeinsam genutzt werden (Single) oder eindeutig für jede Anwendung sein (Multiple). Die Richtlinie für Anwendungsklassenlader steuert die Isolation von Anwendungen, die im System aktiv sind. Bei der Einstellung Single werden Anwendungen nicht isoliert. Bei der Einstellung Multiple werden Anwendungen voneinander isoliert. |
WAR | Standardmäßig laden die Klassenlader für Webmodule die Inhalte der Verzeichnisse
WEB-INF/classes und WEB-INF/lib. Der Klassenlader für Anwendungen ist dem Klassenlader für Webmodule übergeordnet. Sie können
das Standardverhalten ändern, wenn Sie die Richtlinie für WAR-Klassenlader der Anwendung ändern. Die Richtlinie für WAR-Klassenlader steuert die Isolation von Webmodulen. Wenn diese Richtlinie auf Anwendung gesetzt ist, werden die Webmodulinhalte auch vom Klassenlader für Anwendungen geladen (zusätzlich zu den EJB-Dateien, RAR-Dateien, abhängigen JAR-Dateien und gemeinsam genutzten Bibliotheken). Wenn die Richtlinie auf Modul gesetzt ist, empfängt jedes Webmodul seinen eigenen Klassenlader, dem der Klassenlader für Anwendungen übergeordnet ist. Tipp: Die Konsole und
die zugehörige Datei deployment.xml verwenden unterschiedliche Namen für WAR-Klassenladerrichtlinienwerte.
In der Konsole lauten die Werte für die WAR-Klassenladerrichtlinie
Anwendung und Modul. In der Datei deployment.xml hingegen, in der die Richtlinie definiert wird,
lauten die Werte Single anstelle von Anwendung und
Multiple anstelle von Modul. Anwendung ist identisch mit
Single und Modul identisch mit Multiple.
|
Für jeden Anwendungsserver im System können Sie die Richtlinie für die Klassenlader für Anwendungen auf Single oder Multiple setzen. Wenn die Richtlinie für die Klassenlader für Anwendungen auf Singlegesetzt ist, lädt nur ein Klassenlader die EJB-Module, die abhängigen JAR-Dateien und die gemeinsam genutzten Bibliotheken im System. Wenn die Richtlinie für die Klassenlader von Anwendungen auf Multiple gesetzt ist, erhält jede Anwendung einen eigenen Klassenlader für das Laden der EJB-Module, der abhängigen JAR-Dateien und der gemeinsam genutzten Bibliotheken dieser Anwendung.
Klassenlader für Anwendungen lädt Klassen aus Webmodulen, wenn die Anwendungsrichtlinie für WAR-Klassenlader auf Anwendung eingestellt ist. Sollte die Anwendungsrichtlinie für WAR-Klassenlader auf Modul eingestellt sein, erhält jedes WAR-Modul einen eigenen Klassenlader.
Das folgende Beispiel veranschaulicht diese Situation: Wenn die Richtlinie für die Klassenlader von Anwendungen auf Single gesetzt ist, lädt ein Klassenlader alle EJB-Module, die abhängigen JAR-Dateien und die gemeinsam genutzten Bibliotheken aller Anwendungen im Server. Dieser Klassenlader für Anwendungen kann auch Webmodule laden, falls bei einer Anwendung die Richtlinie für die WAR-Klassenlader auf Anwendung gesetzt ist. Anwendungen, deren Richtlinie für die WAR-Klassenlader auf Modul gesetzt ist, verwenden getrennte Klassenlader für Webmodule.
Server's application class-loader policy: Single
Application's WAR class-loader policy: Module
Application 1
Module: EJB1.jar
Module: WAR1.war
MANIFEST Class-Path: Dependency1.jar
WAR Classloader Policy = Module
Application 2
Module: EJB2.jar
MANIFEST Class-Path: Dependency2.jar
Module: WAR2.war
WAR Classloader Policy = Application

Wenn beispielsweise die Richtlinie für die Klassenlader für Anwendungen eines Anwendungsservers auf Multiple gesetzt ist, hat jede Anwendung auf dem Server einen eigenen Klassenlader. Ein Klassenlader für Anwendungen lädt auch Webmodule, wenn die Richtlinie für die WAR-Klassenlader der Anwendung auf Anwendung gesetzt ist. Wenn die Richtlinie auf Modul gesetzt ist, verwendet ein Webmodul einen eigenen Klassenlader.
Server's application class-loader policy: Multiple
Application's WAR class-loader policy: Module
Application 1
Module: EJB1.jar
Module: WAR1.war
MANIFEST Class-Path: Dependency1.jar
WAR Classloader Policy = Module
Application 2
Module: EJB2.jar
MANIFEST Class-Path: Dependency2.jar
Module: WAR2.war
WAR Classloader Policy = Application

Modi für Klassenlader
Der Delegierungsmodus für Klassenlader, auch Reihenfolge der Klassenlader genannt, bestimmt, ob ein Klassenlader das Laden der Klassen an den übergeordneten Klassenlader delegiert. Die folgenden Werte werden für den Klassenladermodus unterstützt:
Klassenladermodus | Beschreibung |
---|---|
Übergeordneter zuerst Auch genannt Mit dem übergeordneten Klassenlader geladene Klassen zuerst. |
Bei Angabe des Klassenladermodus Übergeordneter zuerst delegiert der Klassenlader das Laden von Klassen an den übergeordneten Klassenlader und versucht dann, die Klasse vom lokalen Klassenpfad zu laden. Dies ist die Standardeinstellung der Richtlinie für Klassenlader und für die JVM-Standardklassenlader. |
Übergeordneter zuletzt Auch genannt Mit dem lokalen Klassenlader geladene Klassen zuerst oder Anwendung zuerst. |
Im Klassenladermodus Übergeordneter zuletzt versucht der Klassenlader zuerst, Klassen aus seinem lokalen Klassenpfad zu laden, bevor er das Laden der Klassen an seinen übergeordneten Klassenlader delegiert. Diese Richtlinie ermöglicht dem Klassenlader für Anwendungen, eine im übergeordneten Klassenlader vorhandene Klasse zu überschreiben und seine eigene Version bereitzustellen. |
Die folgenden Einstellungen bestimmen den Modus eines Klassenladers:
- Wenn die Richtlinie für die Klassenlader für Anwendungen auf Single eingestellt ist, definiert der Moduswert auf Serverebene den Modus für den Klassenlader der Anwendung.
- Wenn die Richtlinie für die Klassenlader für Anwendungen eines Anwendungsservers auf Multiple eingestellt ist, ist, definiert der Moduswert auf Anwendungsebene den Modus für den Klassenlader Anwendung.
- Wenn die Richtlinie für WAR-Klassenlader auf Modul eingestellt ist, definiert der Moduswert auf Modulebene den Modus für einen WAR-Klassenlader.
OSGi class loader model
- Jedes Bundle ist nur für die Java-Pakete sichtbar, die es explizit exportiert.
- Jedes Bundle deklariert seine Paketabhängigkeiten explizit.
- Pakete können in bestimmten Versionen exportiert und in bestimmten Versionen oder aus einem bestimmten Versionsbereich importiert werden.
- Es können mehrere Versionen eines Pakets gleichzeitig für verschiedene Clients verfügbar sein.
Weitere Informationen zu OSGi finden Sie im Artikel OSGi-Framework.