WebSphere Application Server TraditionalVersion 9.0 unterstützt die Servlet 3.1-Spezifikation.
Dieser Abschnitt enthält Informationen zu den Features und Verhaltensänderungen für Servlet 3.1.

Neues Feature:
Das Produkt unterstützt Servlet 3.1. In Servlet 3.1 sind Features und Verhaltensänderungen enthalten, die in der Servlet 3.0-Spezifikation eingeführt wurden. Weitere Informationen finden Sie im Artikel
Funktionen des Features Servlet 3.1. Wenn Sie eine Migration von Servlet 2.5 oder früher auf Servlet 3.1 durchführen, berücksichtigen Sie auch die Verhaltensänderungen für
Servlet 3.0. newfeat
Java™ Servlet 3.1 hat viele leistungsfähige Features. Einige dieser Features sind in der Spezifikation Servlet 3.0
nicht vollständig dokumentiert oder erfordern Kompromisse. Lesen Sie die folgenden Informationen, um
die neuen Features sinnvoll einzusetzen.
Annotationen
Annotationen der
Java Servlet
Version 3.0 werden in Webmodulen der Servlet Version 2.5 berücksichtigt, und so kann beispielsweise
ein Servlet im Web bereitgestellt werden.
Gehen Sie bei einem Upgrade der vorausgesetzten Komponenten für eine ältere Anwendung vorsichtig vor,
weil die neuen Annotationen verarbeitet werden, und die JAR-Datei für die vorausgesetzten Komponenten
Annotationen enthalten können, die Sie nicht anwenden möchten.
Hochladen von Dateien
Wenn Sie die Unterstützung für das Hochladen von Dateien
(Mehrfachformulare) verwenden, die in Servlet Version 3.0 neu ist, ist die Standardposition
für das Schreiben von Dateien dieselbe, die mit dem Wert des Servletkontextattribut "javax.servlet.context.tempdir" angegeben wird.
Beispielsweise wird die Datei
C:\opt\WAS\profiles\node1\temp\node1\server1\fragmentTest\fragmentTest24.war für eine Konfiguration
mit den folgenden Attributen erzeugt:
- Ausgangsverzeichnis des Profils: C:\opt\WAS\profiles\node1
- Servername: server1
- Name der Unternehmensanwendung: fragmentTest
- Name des Webmoduls: fragmentTest24.war
Auch relative Pfade sind relativ zu dieser Standardposition.
Sie können
den Wert des Servletkontextattributs "javax.servlet.context.tempdir" so ändern, dass er relativ
zu einem anderen Verzeichnis ist, indem Sie die Systemeigenschaft
"com.ibm.websphere.servlet.temp.dir" setzen. Diese Systemeigenschaft
wirkt sich auf alle Anwendungen serverweit aus.
Wenn Sie für "com.ibm.websphere.servlet.temp.dir" den Wert /foo festlegen, ist das temporäre Verzeichnis der Anwendung
/foo/node1/server1/fragmentTest/fragmentTest24.war.
Wenn Sie den Wert auf Anwendungsebene ändern möchten, verwenden Sie
das JSP-Attribut (JavaServer Pages) "scratchdir".
Weitere Informationen zum Attribut "scratchdir" finden Sie im Artikel "Konfigurationsparameter der JSP-Engine anzeigen".
Programmgesteuerte oder dynamische Konfiguration von HTTP-Sitzungen
Die programmgesteuerte
Konfiguration von HTTP-Sitzungen ermöglicht einer Anwendung, die verwendete
Sitzungskonfiguration über die Konfiguration der Datei
web.xml oder über API-Methodenaufrufe zu ändern.
Nach dem Start der Anwendung kann ein dynamisch geänderter Cookiename nicht mehr geändert werden. Für Sicherheitszwecke können Administratoren die programmgesteuerte Sitzungskonfiguration
für bestimmte Cookies, die von mehreren Anwendungen gemeinsam genutzt werden können, inaktivieren.
Im Allgemeinen ist die Änderung der Cookiekonfiguration sicher, wenn die Anwendung einen eindeutigen
Cookienamen bzw. -pfad verwendet.
Sie können den Standardcookiepfad für jede Anwendung über das Sitzungsmanagement so ändern, dass
das Kontextstammverzeichnis verwendet wird.
Wichtig: Die Pfadänderung kann sich auf bestimmte IBM Erweiterungen auswirken, wie z. B.
die gemeinsame Nutzung von Sitzungen oder die Methode "IBMSessionExt.invalidateAll", die sich auf die Verwendung
eines einzigen Cookies für mehrere Anwendungen stützen.
Dynamische Cookies haben folgenden Einfluss auf zwischengeschaltete Services:
- Ein Unternehmensproxy ruft automatisch ein dynamisches Cookie ab, wenn eine Anwendung gestartet wird, und verwendet das Cookie für die
Sitzungsaffinität.
- Ein DMZ-Proxy in einem Modus mit niedriger oder mittlerer Sicherheit ruft ebenfalls ein dynamisches Cookie ab, wenn eine Anwendung gestartet wird. Für ein DMZ-Proxy in einem Modus mit hoher Sicherheit erfolgt der Abruf nicht automatisch.
Die Anwendung muss aktiv sein, damit die Routing-Informationen des Ziels exportiert werden können.
- Ein Web-Server-Plug-in kann das dynamische Cookie nicht automatisch abrufen, weil es in Bezug auf Konfigurationsdaten nicht mit Anwendungsservern kommuniziert. Sie müssen die Anwendung starten, die Plug-in-Konfiguration generieren,
die Konfiguration an das Plug-in weitergeben und die Konfiguration dann erneut laden, damit das Plug-in das Cookie abrufen kann.
- In der Clusterumgebung muss der generierte Name des dynamischen Cookies auf jedem Server derselbe sein, da sonst die zwischengeschalteten Front-End-Services möglicherweise keine Anforderungen weiterleiten können.