Hinweise zu Java-Servlets

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 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.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_consid
Dateiname:cweb_consid.html