EJB-Inhalt in WAR-Modulen
Verwenden Sie diesen Artikel, um sich mit den Voraussetzungen für das Packen von EJB-Inhalten (Enterprise JavaBeans) in WAR-Module (Web Application Archive, Webanwendungsarchiv) vertraut zu machen.
Unterstützter EJB-Inhalt
Mit Ausnahme explizit genannter Einschränkungen werden alle EJB-Funktionen, die für Beans in EJB-JAR-Modulen unterstützt werden, auch für Beans unterstützt, die in WAR-Module gepackt werden. Eine in ein WAR-Modul gepackte Bean kann dasselbe Verhalten aufweisen wie eine Bean in einem EJB-JAR-Modul.
Alle Typen von Beans der EJB Version 3.x werden in WAR-Modulen und Session-Beans der Versionen 2.x und 1.x unterstützt. Detaillierte Informationen finden Sie in der Spezifikation EJB 3.1.
Packmechanismen
Die Regeln für das Packen von EJB-Inhalt in ein WAR-Modul weichen von den Regeln für das Packen von EJB-Inhalt in ein JAR-Modul ab.
- flexibel in der Verzeichnisstruktur WEB-INF/classes
- in einer JAR-Datei im Verzeichnis WEB-INF/lib
Sie können die Beanklasse "com.foo.MyBean" beispielsweise im WAR-Modul flexibel an der folgenden Position platzieren: WEB-INF/classes/com/foo/MyBean.class.
Sie können diese Beanklasse aber auch in die Datei myJar.jar einfügen, die dann an der folgenden Position platziert wird: WEB-INF/lib/myJar.jar.
Ein WAR-Modul kann flexibel in der Verzeichnisstruktur WEB-INF/classes platzierten Beancode sowie Beancode in JAR-Dateien im Verzeichnis WEB-INF/lib enthalten. Es ist auch zulässig, dass ein WAR-Modul den gesamten Beancode in der Verzeichnisstruktur WEB-INF/classes und keinen Beancode im Verzeichnis WEB-INF/lib oder den gesamten Beancode in JAR-Dateien im Verzeichnis WEB-INF/lib und keinen Beancode in WEB-INF/classes enthält.
Die Existenz mehrerer JAR-Dateien im Verzeichnis WEB-INF/lib, die alle Beancode enthalten können, ist ebenfalls zulässig.
Wenn dieselbe Beanklasse flexibel in der Verzeichnisstruktur WEB-INF/classes platziert und zusätzlich auch in einer JAR-Datei im Verzeichnis WEB-INF/lib enthalten ist, wird die Instanz der Klasse, die flexibel in der Verzeichnisstruktur WEB-INF/classes platziert ist, geladen, und die Instanz in der JAR-Datei im Verzeichnis WEB-INF/lib wird ignoriert.
Wenn dieselbe Beanklasse in zwei verschiedenen JAR-Dateien im Verzeichnis WEB-INF/lib enthalten ist, ist nicht bekannt, welche Instanz der Klasse geladen und welche ignoriert wird. Der Server wählt zur Laufzeit eine beliebige Klasseninstanz aus, lädt diese und ignoriert die andere Klasseninstanz.
- WEB-INF/classes/META-INF/persistence.xml
- WEB-INF/lib/MyEntity.jar
IWAE0068W The EJB deployment descriptor META-INF/ejb-jar.xml in the library archive foo.jar file is ignored.
The product does not process the META-INF/ejb-jar.xml deployment descriptor in library archives. Move the META-INF/ejb-jar.xml deployment descriptor from the library archive to the WEB-INF directory in the WAR module.
Ein WAR-Modul muss Version 2.5 oder höher haben, um EJB-Inhalt enthalten zu können. EJB-Inhalt in einem WAR-Modul der Version 2.4 oder älter wird ignoriert.

Technische Unterschiede bei Enterprise-Beans in einer WAR-Datei
Die folgende Liste enthält die wichtigsten technischen Unterschiede zwischen Beans in einem WAR-Modul und Beans in einem EJB-JAR-Modul:
- Namespace gemeinsam genutzter Komponenten
Alle Komponenten in einem WAR-Modul verwenden denselben Komponentennamespace. Das bedeutet, dass alle EJB-Komponenten in der WAR-Datei und alle Komponenten, die keine EJB-Komponenten sind, wie z. B. Servlets, einen einzigen Komponentennamespace nutzen. Eine EJB-Komponente in einem EJB-JAR-Modul hat hingegen einen eigenen privaten Komponentennamespace, der von keiner anderen Komponente genutzt wird.
Der gemeinsam genutzte Komponentennamespace hat wichtige Auswirkungen. 1. Eine Komponente (EJB oder eine andere Komponente) kann eine Referenz deklarieren, und eine andere Komponente kann den Komponentennamespace nach dieser Referenz durchsuchen. 2. Von einer Komponente deklarierte Referenzen können mit Referenzen in Konflikt stehen, die von einer anderen Komponente deklariert werden. Eine EJB in einem EJB-JAR-Modul hingegen kann keine Referenz, die von einer anderen EJB oder einer anderen Komponente deklariert wurde, im Komponentennamespace suchen, und es ist nicht möglich, dass eine von der EJB deklarierte Referenz im Komponentennamespace mit einer Referenz in Konflikt steht, die von einer anderen Komponente deklariert wird, selbst wenn die Referenzen denselben Namen haben.
Bei der Verwendung eines gemeinsam genutzten Namespace kann dieselbe Referenz mehrfach deklariert werden, solange diese Referenzdeklarationen nicht miteinander in Konflikt stehen. Wenn die Referenzdeklarationen nicht in Konflikt stehen, verhält sich der Server so, als wäre die Referenz nur ein einziges Mal deklariert worden.
Wenn Referenzdeklarationen in Konflikt stehen, wird eine Fehlernachricht ausgegeben, und die Anwendung kann nicht gestartet werden. Für jede Referenz, für die ein Konflikt festgestellt wird, wird eine Warnung ausgegeben. Die Warnung enthält den Namen der betroffenen Referenz sowie mehrere Werte, die dieser Referenz zugeordnet sind. Nachdem alle Warnungen ausgegeben wurden, wird eine Ausnahme ausgelöst.
- Positionen der EJB-Deskriptordateien
Die Implementierungsdeskriptordatei ejb-jar.xml und alle anderen Deskriptordateien müssen im Verzeichnis WEB-INF der WAR-Datei abgelegt werden. Alle Instanzen einer EJB-Deskriptordatei, die sich an anderen Positionen in der WAR-Datei befinden, einschließlich der Instanzen im Verzeichnis META-INF einer JAR-Datei im Verzeichnis WEB-INF/lib, werden ignoriert.
- Bestimmen, ob Annotationen gescannt werden
Die Regeln für die Durchführung eines Annotationsscans sind für EJB-JAR- und WAR-Module jeweils verschieden. Der vollständige Regelsatz wird im Artikel "Übersicht über das Packen von Modulen der EJB Version 3.x" beschrieben.
- Klassenladen und Sichtbarkeit
Das häufigste Verwendungsmuster für EJB-Klassen, die in einem WAR-Modul gepackt sind, sind Aufrufe über lokale Methoden aus Webkomponenten, die in dasselbe Modul gepackt wurden. Diese EJB-Klassen können aber auch über Methodenfernaufrufe oder von Clients in anderen Modulen aufgerufen werden. In diesen Fällen müssen Sie die Sichtbarkeitsregeln von EJB-Klassen, die in einem WAR-Modul gepackt sind, kennen. Die Sichtbarkeitsregeln unterscheiden sich im Vergleich zu EJB-Klassen, die in einem JAR-Modul gepackt sind.
Im Fall von EJB-Methodenfernaufrufen gibt es keine Unterschiede bei der Sichtbarkeit, die durch das Packen der EJB-Klassen in ein WAR-Modul entstanden sind. Die EJBs sind in den globalen Namensbereich gebunden und können von der Komponente gesucht oder in Komponenten in anderen Modulen injiziert werden. Der ferne Client muss Methodenaufrufe mit der geeigneten Stubklasse ausführen. Die Generierung von Stubklassen wird in diesem Artikel im Abschnitt "Stubgenerierung" beschrieben.
Im Fall lokaler EJB-Methodenaufrufe aus Komponenten in anderen Modulen gibt es Unterschiede bei der Sichtbarkeit, weil die EJBs in einem WAR-Modul gepackt sind. Diese Unterschiede bei der Sichtbarkeit werden durch Auswirkungen des Klassenladers verursacht, die berücksichtigt werden müssen.
Der Inhalt aller EJB-JAR-Module in der gesamten Anwendung wird von einer einzigen Instanz des Anwendungsklassenladers geladen.
Der Inhalt eines WAR-Moduls hingegen wird von einem speziellen Klassenlader für dieses WAR-Modul geladen. Die Instanz des Anwendungsklassenladers, die verwendet wird, um den gesamten EJB-JAR-Inhalt zu laden, ist die übergeordnete Instanz aller Klassenladerinstanzen, die zum Laden von WAR-Inhalten verwendet werden.
Die Sichtbarkeit einer Klasse wird durch die Klassenladerinstanz beeinflusst, die die Klasse geladen hat. Eine Klassenladerinstanz kann Klassen sehen, die sie selbst geladen hat, und Klassen, die von einem übergeordneten Klassenlader geladen wurden. Ein Klassenlader kann jedoch keine Klassen sehen, die von einem anderen Klassenlader oder dessen übergeordneten Klassenladern geladen wurden.
Deshalb können Klassen, die von einem speziellen Klassenlader für ein WAR-Modul geladen wurden, zwar Klassen in einem EJB-JAR-Modul, aber keine Klassen in einem anderen WAR-Modul sehen. Klassen in einem EJB-JAR-Modul können keine Klassen in WAR-Modulen sehen. Angenommen, ein EJB-JAR-Modul mit dem Namen ejb3.jar enthält EJB-Inhalt, und die Dateien ejb1.jar und ejb2.jar enthalten ebenfalls EJB-Inhalt:- Wenn die Dateien ejb1.jar und ejb2.jar als EJB-JAR-Module installiert sind, werden die Inhalte der Dateien ejb1.jar, ejb2.jar und ejb3.jar in derselben Klassenladerinstanz geladen, die auch verwendet wird, um alle anderen EJB-JAR-Module in der Anwendung zu laden. In diesem Fall können die Klassen in allen drei JAR-Dateien einander sehen, weil sie alle von derselben Klassenladerinstanz geladen wurden.
- Wenn die Dateien ejb1.jar und ejb2.jar im Verzeichnis WEB-INF/lib einer WAR-Datei enthalten sind, werden die Inhalte der Dateien ejb1.jar und ejb2.jar von einer einzigen Klassenladerinstanz geladen. Allerdings ist dieser Klassenlader nicht derselbe, der auch zum Laden des Inhalts der Datei ejb3.jar und der Inhalte anderer EJB-JAR-Module in der Anwendung verwendet wird. In diesem Fall können die Klassen in den Dateien ejb1.jar und ejb2.jar einander und auch die Klassen in der Datei ejb3.jar sehen. Die Klassen in der Datei ejb3.jar können weder die Klassen in der Datei ejb1.jar noch die Klassen in der Datei ejb2.jar sehen.
- Wenn die Datei ejb1.jar im Verzeichnis WEB-INF/lib der Datei firstWar.war enthalten ist und die Datei ejb2.jar im Verzeichnis WEB-INF/lib der Datei secondWar.war, wird der Inhalt der Datei ejb1.jar in einer Klassenladerinstanz geladen, der Inhalt der Datei ejb2.jar in einer zweiten Klassenladerinstanz und der Inhalt der Datei ejb3.jar sowie aller anderen EJB-JAR-Module in der Anwendung in einer dritten Klassenladerinstanz. In diesem Fall können die Klassen in der Datei ejb1.jar und die Klassen in der Datei ejb2.jar einander nicht sehen, aber sie können die Klassen in der Datei ejb3.jar sehen. Die Klassen in der Datei ejb3.jar können weder die Klassen in der Datei ejb1.jar noch die Klassen in der Datei ejb2.jar sehen.
Solche Komplikationen bei den Klassenladern können Sie vermeiden, wenn Sie die EJB-Schnittstellenklassen in eine gemeinsam genutzte Bibliothek packen.Bewährtes Verfahren: Dieselbe Klasse sollte nicht gleichzeitig in ein EJB-JAR-Modul und in ein WAR-Modul in derselben Anwendung gepackt werden. Die Verwendung derselben Klasse an mehreren Positionen in derselben Anwendung kann zu Verwirrungen bezüglich der Instanz führen, die geladen und zur Laufzeit verwendet wird. Diese Unterscheidung kann eine Rolle spielen, wenn die beiden Dateien mit der Erweiterung .class verschiedene Versionen der Klasse darstellen. Um dieses Szenario zu vermeiden, packen Sie die Klassendatei (.class) nur an einer Position, oder ändern Sie die Paketstruktur der Klasse so, dass der vollständig qualifizierte Name der Klasse im WAR-Modul sich von dem vollständig qualifizierten Name der Klasse im EJB-JAR-Modul unterscheidet.bprac
- Anwendungsprofilerweiterung
Die Anwendungsprofilerweiterung wird für in WAR-Module gepackte EJB-Klassen nicht unterstützt.
Stubgenerierung
Der Fernzugriff auf EJB-Methoden setzt die Verwendung von Stubklassen auf der Clientseite voraus. Für die meisten Clientumgebungen generiert die Produktlaufzeit die erforderlichen Stubklassen automatisch. Eine Ausnahme ist die Thin-Client-Umgebung. Die Stubklassen müssen für Thin Clients manuell generiert und mit dem Client gepackt werden.
Verwenden Sie das Tool createEJBStubs für die Generierung von Stubs, wenn der EJB-Inhalt in ein WAR-Modul gepackt ist, unabhängig von der EJB-Version.
Weitere Informationen finden Sie im Artikel "Befehl zum Erstellen von Stubs".

Inhalt der EJB Versionen 2.x und 1.x in einem WAR-Modul
Mit Ausnahme von Entity-Beans wird Inhalt der EJB Versionen 2.x und 1.x in einem WAR-Modul unterstützt.
Ein in eine WAR-Datei gepacktes Modul der Version 2.x oder 1.x erfordert einen Implementierungsdeskriptor ejb-jar.xml der Version 2.x bzw. 1.x im Verzeichnis WEB-INF des WAR-Moduls. Wenn XMI-Bindungs- und -Erweiterungsdateien vorhanden sind, müssen diese ebenfalls in das Verzeichnis WEB-INF eines WAR-Moduls gepackt werden.
Session-Beans und Message-driven Beans, die sie entsprechend dem Codierungsstil 2.x oder 1.x implementieren, können in ein WAR-Modul gepackt werden.
BMP- (Bean Managed Persistence, Bean-gesteuerte Persistenz) und CMP-Entity-Beans (Container Managed Persistence, containergesteuerte Persistenz) werden in einem WAR-Modul nicht unterstützt.
Die Services zur Erstellung von Anwendungsprofilen und Zugriffsarten werden in einem WAR-Modul nicht unterstützt. Die in einem WAR-Modul gefundenen Session-Beans können nicht auf die Tasks zur Erstellung von Anwendungsprofilen zugreifen.
EJB-Inhalt, den Sie entsprechend dem Codierungsstil 3.x und den Codierungsstilen 2.x und 1.x implementieren, kann zusammen in ein einziges WAR-Modul gepackt werden. In diesem Fall müssen Sie jedoch alle Bindungs- und Erweiterungsinformationen mit der XML-Version der Dateien und nicht mit der XMI-Version deklarieren.
Vorhandenen EJB-Inhalt aus EJB-JAR-Modulen in WAR-Module verschieben
Eine Methode ist das Verschieben der vorhandenen EJB-JAR-Datei in das Verzeichnis WEB-INF/lib der WAR-Datei. Entfernen Sie anschließend die Deskriptordateien aus dem Verzeichnis META-INF der JAR-Datei und speichern Sie sie im Verzeichnis WEB-INF der WAR-Datei.
Eine zweite Methode ist das Verschieben der Klassendateien aus der EJB-JAR-Datei an die richtige Position unterhalb des Verzeichnisses WEB-INF/classes im WAR-Modul. Anschließend entfernen Sie die Deskriptordateien aus dem Verzeichnis META-INF der JAR-Datei und speichern Sie sie im Verzeichnis WEB-INF der WAR-Datei.
Wenn mehrere EJB-JAR-Module in ein einziges WAR-Modul verschoben werden, müssen Sie die Inhalte aller Deskriptordateien, die in den Verzeichnissen META-INF der EJB-JAR-Module gefunden wurden, zu einer einzigen Version der Deskriptordateien zusammenführen, die sich jetzt im Verzeichnis WEB-INF der WAR-Datei befinden. Beispiele für Deskriptordateien, die zusammengeführt werden können, sind ejb-jar.xml, ibm-ejb-jar-bnd.xml, ibm-ejb-jar-ext.xml und ibm-ejb-jar-ext-pme.xml.
Sie müssen die Referenzen, die von den verschiedenen Komponenten im WAR-Modul deklariert werden, EJBs und anderen Komponenten, überprüfen, um sicherzustellen, dass sie nicht miteinander in Konflikt stehen, da alle Komponenten im WAR-Modul einen einzigen gemeinsamen Komponentennamespace nutzen.
Sie müssen die XMI-Bindungs- und -Erweiterungsdateien, die aus einem EJB-JAR-Modul in ein WAR-Modul an mehrere Positionen verschoben wurden, ändern, um Referenzen auf META-INF/ejb-jar.xml zu entfernen und durch WEB-INF/ejb-jar.xml zu ersetzen.
EJB-Funktionen, die in EJB-JAR-Modulen, aber nicht in WAR-Modulen unterstützt werden
- BMP- und CMP-Entity-Beans
- Startup-Beans mit einem Stil vor EJB Version 3.1 Achtung: Singleton-Startup-Beans, die nach EJB 3.1 wurden, werden unterstützt.
CWMDF0025E: Entity-Beans in EJB-WAR-Modulen sind gemäß der Spezifikation EJB 3.1 nicht zulässig.
WSVR0039E: Das EJB-JAR foo.war kann nicht gestartet werden: Entity-Beans in EJB-WAR-Modulen sind gemäß der
Spezifikation EJB 3.1 nicht zulässig. Die Bean foo im Modul foo.war muss in ein eigenständiges EJB-Modul verschoben werden. Im Protokoll finden Sie eine vollständige Liste ungültiger Entity-Beans in einem WAR-Modul.