Webcontainer

In diesem Abschnitt werden die bekannten Probleme mit Webcontainern sowie ihre Lösungen beschrieben.

Wird unter Windows eine Anwendung mit --precompilejsp=true bereitgestellt, können JAR-Dateien der Anwendung gesperrt werden, sodass das Aufheben der Bereitstellung oder eine neue Bereitstellung zu einem späteren Zeitpunkt nicht möglich ist. (Nr 5004315)

Wenn Sie beim Bereitstellen einer Anwendung unter Windows eine Vorkompilierung der JSPs anfordern, funktionieren spätere Versuche zum Aufheben der Bereitstellung dieser Anwendung oder zum erneuten Bereitstellen der Anwendung (oder einer anderen Anwendung mit derselben Modul-ID) nicht wie erwartet. Das Problem liegt darin begründet, dass durch die JSP-Vorkompilierung JAR-Dateien in Ihrer Anwendung geöffnet, jedoch nicht wieder geschlossen werden, und Windows verhindert, dass zur Aufhebung der Bereitstellung diese Dateien gelöscht oder zur erneuten Bereitstellung diese Dateien überschrieben werden.

Beachten Sie, dass das Aufheben der Bereitstellung erfolgreich durchgeführt wird, bis die Anwendung aus Application Server logisch entfernt wird. Außerdem gibt das asadmin-Programm keine Fehlermeldung aus, obwohl das Anwendungsverzeichnis und die gesperrten JAR-Dateien auf dem Server weiterhin vorhanden sind. Die Protokolldatei des Servers enthält jedoch Fehlermeldungen, die Sie über den fehlgeschlagenen Löschvorgang der Dateien und des Verzeichnisses der Anwendung informieren.

Die Versuche zum erneuten Bereitstellen der Anwendung nach der Aufhebung der Bereitstellung schlagen fehl, da der Server versucht, die vorhandenen Dateien und Verzeichnisse zu entfernen, was ebenfalls nicht möglich ist. Dieser Fehler tritt beispielsweise auf, wenn Sie versuchen, eine Anwendung mit der Modul-ID der ursprünglich bereitgestellten Anwendung bereitzustellen, da der Server die Modul-ID für die Auswahl eines Verzeichnisses für das Speichern der Dateien der Anwendung verwendet.

Aus demselben Grund schlägt auch der Versuch fehl, die Anwendung erneut bereitzustellen, ohne dass die Bereitstellung zuvor aufgehoben wurde.

Diagnose

Wenn Sie die Anwendung erneut bereitstellen möchten oder die Anwendung bereitstellen möchten, nachdem Sie die Bereitstellung der Anwendung zuvor aufgehoben haben, gibt das asadmin-Programm eine Fehlermeldung aus, die etwa der folgenden Meldung entspricht:

Beim Ausführen des Befehls ist ein Ausnahmefehler aufgetreten. 
Die Ausnahmemeldung lautet: CLI171 Bereitstellung des Befehls 
fehlgeschlagen: Bereitstellung der Anwendung in der Domäne 
fehlgeschlagen; Bereitstellung nicht möglich. Modulverzeichnis ist gesperrt 
und kann nicht gelöscht werden.

Lösung

Wenn Sie bei der Bereitstellung einer Anwendung --precompilejsps=false (die Standardeinstellung) festlegen, tritt dieses Problem nicht auf. Beachten Sie, dass beim ersten Aufruf der Anwendung die JSP-Kompilierung ausgelöst wird, sodass die Antwortzeit für den ersten Aufruf länger ist als für folgende Aufrufe.

Beachten Sie weiterhin, dass Sie im Falle einer Vorkompilierung den Server stoppen und erneut starten müssen, bevor Sie die Bereitstellung der Anwendung aufheben oder die Anwendung erneut bereitstellen. Durch den Prozess des Herunterfahrens werden die gesperrten JAR-Dateien wieder freigegeben, sodass die Aufhebung der Bereitstellung oder die erneute Bereitstellung nach dem Neustart erfolgreich ist.

WAR kann nicht mit Servlet 2.4-basierter Datei web.xml, die ein leeres <load-on-startup>-Element enthält, bereitgestellt werden. (Nr. 6172006)

Das optionale load-on-startup servlet-Element in der Datei web.xml gibt an, dass das zugehörige Servlet als Teil des Startvorgangs der die Deklaration ausführenden Webanwendung geladen und initialisiert werden muss.

Für dieses Element kann optional eine ganze Zahl angegeben werden, mit der festgelegt wird, in welcher Reihenfolge das Servlet mit Bezug auf die anderen Servlets der Anwendung geladen und initialisiert werden soll. Wenn für <load-on-startup> kein Wert angegeben ist, wird keine bestimmte Reihenfolge berücksichtigt und es wird lediglich festgelegt, dass das Servlet beim Start der entsprechenden Webanwendungen geladen und initialisiert wird.

Das Servlet 2.4-Schema für web.xml unterstützt keine leere <load-on-startup> mehr; dies bedeutet, dass bei Verwendung einer Servlet 2.4-basierten web.xml eine Ganzzahl angegeben werden muss. Wenn eine leere <load-on-startup> angegeben wurde, wie in <load-on-startup/>, schlägt die Validierung von web.xml basierend auf dem Servlet 2.4-Schema für web.xml fehl, wodurch die Bereitstellung der Webanwendung fehlschlägt.

Rückwärtskompatibilität: Die Angabe eines leeren <load-on-startup>-Elements ist mit Servlet 2.3-basierten web.xml-Dateien nach wie vor möglich.

Lösung

Geben Sie <load-on-startup>0</load-on-startup> an, wenn Sie eine Servlet 2.4-basierte web.xml-Datei verwenden, um anzugeben, dass die Servlet-Lastenreihenfolge irrelevant ist.

JSP-Seite kann auf Servern mit geringen Ressourcen nicht kompiliert werden (Nr. 6184122)

Der Zugriff auf die JSP-Seite erfolgt, aber die eigentliche Kompilierung wird durchgeführt und das Serverprotokoll enthält die Fehlermeldung "Unable to execute command" mit folgenden Stapelverlaufsinformationen:

at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.
launch(Execute.java:416) 
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) 
at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.
executeExternalCompile(DefaultCompilerAdapter.java:448) 
at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
(JavacExternal.java:81) 
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) 
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) 
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)

Lösung

Setzen Sie den Schalter für die JSP-Kompilierung fork auf false.

Wählen Sie eine der folgenden Vorgehensweisen:

• Auf globaler Basis setzen Sie den Parameter "fork init" von JspServlet in ${S1AS_HOME}/domains/domain1/config/default-web.xml auf "false":

  <servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet>

• Um den Wert für eine einzelne Webanwendung festzulegen, setzen Sie in sun-web.xml den JSP-Konfigurationsparameter "fork" auf "false":

  <sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app>

Diese Einstellung verhindert, dass ant neue Prozesse für die javac -Kompilierung erzeugt.

Application Server unterstützt nicht das Add-On auth-passthrough von Web Server 6.1. (Nr. 6188932)

Sun Java System Application Server Enterprise Edition 8.2 fügt Unterstützung für die Funktionalität hinzu, die durch das Plulgin auth-passthrough bereitgestellt wird, das in Sun Java System Application Server Enterprise Edition 7.1 enthalten ist. In Application Server Enterprise Edition 8.2 ist jedoch die Plugin-Funktion auth-passthrough anders konfiguriert.

Die Funktion des Plugins auth-passthrough in Application Server Enterprise Edition 7.1 hat sich in zweischichtigen Bereitstellungsszenarien als nützlich erwiesen, für die Folgendes gilt:

• Die Instanz von Application Server wird durch eine zweite Firewall hinter der firmeneigenen Firewall geschützt.

• Es sind keine direkten Client-Verbindungen mit der Instanz von Application Server zulässig.

In derartigen Netzwerkarchitekturen stellen Clients eine Verbindung mit einem Front-End-Webserver her, der mit der Plugin-Funktion service-passthrough konfiguriert wurde, und leiten HTTP-Anforderungen zum Verarbeiten an die Proxy-Instanz von Application Server weiter. Die Instanz von Application Server kann lediglich Anforderungen vom Proxy-Webserver erhalten. Direkte Anforderungen von Client-Hosts sind nicht möglich. Folglich erhalten alle auf der Proxy-Instanz von Application Server bereitgestellten Anwendungen, die Client-Informationen, wie z. B. die IP-Adresse des Clients, abfragen, die IP des Proxy-Hosts, da dies der tatsächliche Ursprungs-Host der weitergeleiteten Anforderung ist.

In Application Server Enterprise Edition 7.1 kann die Funktion des Plugins auth-passthrough auf der Proxy-Instanz von Application Server konfiguriert werden, um die Informationen des Remote-Clients allen auf ihm bereitgestellten Anwendungen direkt zur Verfügung zu stellen, als ob die Proxy-Instanz von Application Server die Anfrage auf direkte Weise und nicht über einen intermediären Webserver erhalten hätte, auf dem das Plugin service-passthrough ausgeführt wird.

In Application Server Enterprise Edition 8.2 kann die Funktion auth-passthrough aktiviert werden, indem die Eigenschaft authPassthroughEnabled des Elements <http-service> in der Datei domain.xml wie folgt auf TRUE gesetzt wird:

<property name="authPassthroughEnabled" value="true"/>

Dieselben Sicherheitserwägungen für die Funktion des Plugins auth-passthrough in Application Server Enterprise Edition 7.1 gelten auch für die Eigenschaft authPassthroughEnabled in Application Server Enterprise Edition 8.2. Da authPassthroughEnabled ermöglicht, Informationen zu umgehen, die für Authentifizierungszwecke verwendet werden können (wie z. B. die IP-Adresse, von der die Anforderung ausging, oder das SSL-Clientzertifikat), ist es erforderlich, dass nur vertrauenswürdigen Clients oder Servern das Recht gewährt wird, eine Verbindung mit einer Instanz von Application Server Enterprise Edition 8.2 herzustellen, wenn authPassthroughEnabled auf TRUE gesetzt ist. Als Vorsichtsmaßnahme wird empfohlen, dass nur Server hinter der firmeneigenen Firewall mit dem auf TRUE gesetzten Befehl authPassthroughEnabled konfiguriert werden. Ein Server, der über das Internet aufgerufen werden kann, darf niemals mit dem auf TRUE gesetzten Befehl authPassthroughEnabled konfiguriert werden.

Beachten Sie, dass in dem Fall, wenn ein Proxy-Webserver mit dem Plugin service-passthrough konfiguriert wurde und Anforderungen an eine Instanz von Application Server 8.1, Update 2 mit dem auf TRUE gesetzten Befehl authPassthroughEnabled weiterleitet, die SSL-Clientauthentifizierung auf dem Webserver-Proxy aktiviert sowie auf der Proxy-Instanz von Application Server 8.1, Update 2 deaktiviert werden kann. In diesem Fall behandelt die Proxy-Instanz von Application Server 8.1, Update 2 die Anforderung immer noch so, als wäre diese per SSL authentifiziert worden und stellt das SSL-Zertifikat des Clients allen bereitgestellten Anwendungen zur Verfügung, wenn diese es anfordern.

Bei der Erstellunge eines HTTP-Listener mit --enabled=false ist der Listener nicht deaktiviert. (Nr. 6190900)

Wenn ein httplistener mit dem Flag --enabled=false erstellt wird, wird der Listener dennoch nicht deaktiviert. Das Flag --enabled bleibt ohne Wirkung, wenn es gleichzeitig mit der Erstellung eines Listeners verwendet wird.

Lösung

Erstellen Sie den Listener im aktivierten Zustand und deaktivieren Sie ihn später manuell.

Erneute Bereitstellung unter Windows scheitert, da verify_file_user_exists_common nicht ausgeführt wird. (Nr. 6490227)

Wenn unter Windows eine Anwendung erneut bereitgestellt wird, die vor der Bereitstellung einen Benutzer erstellt, schlägt der Befehl create-file-user möglicherweise fehl, da verify_file_user_exists_common nicht ausgeführt wird (obwohl er aufgerufen wird) und nicht meldet, dass der Benutzer bereits vorhanden ist. Die Ausführung des deploy-Ziels wird an diesem Punkt abgebrochen und die Bereitstellung bzw. die Aufhebung der Bereitstellung scheitert.

Lösung

Löschen Sie zuerst die Dateibenutzer, die das keydel-Ziel verwenden und führen Sie dann das deploy-Ziel erneut aus:

asant keydel
asant deploy