Änderungen bezüglich Anwendungen

Zwischen Enterprise Server v3 und Enterprise Server v2 bestehen Unterschiede im Hinblick auf Anwendungen. In diesem Abschnitt werden einige dieser Unterschiede erläutert.

Option force

Der Standardwert der Option force für die Bereitstellung lautet in Enterprise Server v3 false. In Enterprise Server v2 lautete der Standardwert true. In Enterprise Server v3 müssen Sie die Option für die erneute Bereitstellung explizit auf true setzen. Diese Option wird während des Upgrade-Verfahrens nicht automatisch festgelegt. Diese Änderung wurde vorgenommen, um das versehentliche Überschreiben des Inhalts einer vorhandenen Anwendung zu verhindern. Dies gilt sowohl für die Administration Console als auch für das Befehlszeilendienstprogramm.

Der Befehl asadmin redeploy ist ebenfalls neu in Enterprise Server v3 und entspricht --force=true. Die Option force ist nur auf den Befehl deploy (Befehlszeilenschnittstelle) und den Bildschirm deploy (Konsole) anwendbar, nicht jedoch auf den Befehl redeploy und den Bildschirm redeploy.

Anwendungen und generiertes Verzeichnislayout

Enterprise Server v2 enthielt zwei Unterverzeichnisse für das Anwendungs-Repository: applications/j2ee-apps und applications/j2ee-modules. Diese Unterverzeichnisse sind in Enterprise Server v3 nicht vorhanden (es gibt keine Ebene j2ee-apps oder j2ee-modules). Die Bereitstellung eines eigenständigen Moduls wie foo.war, das in Enterprise Server v2 in applications/j2ee-modules/foo gespeichert war, befindet sich in Enterprise Server v3 nun in applications/foo. Unternehmensanwendungen und eigenständige Module nutzen im Wesentlichen denselben Namensraum gemeinsam, sodass die Zwischenverzeichnisebene nicht benötigt wurde.

domain.xml-Element application

Elemente früherer Versionen wie web-module, ejb-module usw. sind in Enterprise Server v3 veraltet und wurden durch das neue Element application ersetzt. Weitere Informationen zum Element application finden Sie im Abschnitt application in Sun GlassFish Enterprise Server v3 Domain File Format Reference.

Während eines Upgrades werden Enterprise Server v2-Anwendungen am neuen Speicherort applications/ mit dem neuen Element application in der Datei domain.xml erneut bereitgestellt. Alle für Enterprise Server v3 bereitgestellten neuen Anwendungen werden mit der neuen Verzeichnisstruktur und dem neuen Element bereitgestellt.

Strengere Regeln für die JAR-Sichtbarkeit

In Java EE 6 gelten strengere Regeln für die JAR-Sichtbarkeit als in Java EE 5. Dies führt dazu, dass einige ältere Anwendungen möglicherweise nicht ausgeführt werden können.

Die Java EE 6-Spezifikation definiert strenge Regeln dafür, welche JAR-Dateien aus einer Enterprise Archive-(EAR-)Datei sichtbar sind. Lesen Sie insbesondere Abschnitt EE.8.3.3. Vor allem Anwendungsclient-Module sollten keinen Zugriff auf EJB-JAR-Dateien haben, es sei denn, das Manifest Class-Path der JAR-Datei des Anwendungsclients verweist explizit auf die EJB-JAR-Dateien.

Dies ist eine Änderung gegenüber Enterprise Server v2; in dieser Version hatten Anwendungsclients automatisch Zugriff auf alle EJB-JAR-Dateien in der EAR-Datei und alle JAR-Dateien auf der obersten Ebene der EAR-Datei. Um den strengeren Regeln der Spezifikationssprache zu entsprechen, kann Enterprise Server v3 Anwendungsclients des Zugriff auf diese JAR-Dateien nicht automatisch gewähren.

Diesem neuen, strengeren Verhalten, das von Java EE 6 gefordert wird, können Sie wie folgt begegnen:

• Wenn die Anwendung für eine Enterprise Server v2-Domäne bereitgestellt wird, behält Upgrade Tool das Enterprise Server v2-Verhalten für diese Anwendung in dieser Domäne. Weitere Informationen zum Upgrade-Verfahren finden Sie im Sun GlassFish Enterprise Server v3 Upgrade Guide .

• Ändern Sie das Manifest Class-Path des Clients so, dass es explizit auf die JAR-Dateien verweist, von denen es abhängt. Class-Path darf keine JAR-Dateien im Bibliotheksverzeichnis der EAR-Datei auflisten. Gemäß Spezifikation stehen alle JAR-Dateien in diesem Verzeichnis allen Modulen in der EAR-Datei zur Verfügung. Dieses Verzeichnis ist standardmäßig /lib; durch Verwendung von library-directory im Deskriptor von application.xml kann alternativ ein anderes Verzeichnis festgelegt werden.

• Stellen Sie die EAR-Datei mit der optionalen Einstellung --property compatibility=v2 bereit. Dadurch bleibt das Enterprise Server v2-Verhalten für diese Anwendung erhalten, wenn sie für Enterprise Server v3 bereitgestellt wird.

Dieses geänderte Verhalten ist auch Thema in Kapitel 1, Application Server Compatibility Issues in Sun GlassFish Enterprise Server v3 Upgrade Guide.

Anwendungsclient-Befehle deploy --retrieve und get-client-stubs

In Sun GlassFish Enterprise Server v3 wird bei Ausführung der Befehle deploy --retrieve und get-client-stubs nicht länger nur eine JAR-Datei in das lokale Verzeichnis heruntergeladen, wie es in Enterprise Server v2 der Fall war. Zwar wird localdir/myAppClient.jar nach wie vor in Enterprise Server v3 erstellt und kann als Ziel im Befehl appclient verwendet werden; zusätzlich wird jedoch ein weiteres Verzeichnis (localdir/myAppClient ) erstellt, das seinerseits weitere Dateien enthalten kann.

Wenn Sie bisher die in Enterprise Server v2 heruntergeladene einzelne JAR-Datei kopiert haben, um die Anwendungsclient-Komponenten von einem Ort an einen anderen zu verschieben, können Sie in Enterprise Server v3 nicht mehr so vorgehen. Hierfür muss nun der Befehl asadmin get-client-stubs verwendet werden. Weitere Informationen zu diesem Befehl finden Sie unter get-client-stubs(1).

Sollten Sie sich dennoch für das Kopierverfahren entscheiden, müssen Sie nicht nur die Datei localdir/myAppClient.jar kopieren (wie in Enterprise Server v2), sondern auch den gesamten Inhalt des Verzeichnisses localdir/myAppClient.