Änderungen beim Servletverhalten

Die Servlet 3.1-Implementierung beinhaltet Verhaltensänderungen, die bewirken können, dass eine für Servlet 3.0 geschriebene Anwendung sich anders verhält oder fehlschlägt, wenn Sie das Feature Servlet 3.1 verwenden.

Sie können für jede Serverinstanz zwischen den Implementierungen der Features Servlet 3.0 und Servlet 3.1 wählen und die Verhaltensänderungen berücksichtigen. Wenn das erforderliche Verhalten Teil des Features Servlet 3.1 ist, müssen Sie dieses Feature verwenden. Wenn sich die Verhaltensänderungen im Feature Servlet 3.1 auf eine bestehende Anwendung negativ auswirken, wird durch Verwendung des Features Servlet 3.0 sichergestellt, dass das bestehende Verhalten für die betreffende Anwendung beibehalten wird. Es ist nicht möglich, in einem Server sowohl das Feature Servlet 3.0 als auch das Feature Servlet 3.1 zu verwenden. Es ist falsch, beide Features zu konfigurieren, da in diesem Fall keines der beiden Servlet-Features geladen wird.

Folgende Verhaltensänderungen werden eingeführt:
  • Änderungen, die aufgrund von Präzisierungen in der Servlet 3.1-Spezifikation erforderlich sind.
  • Änderungen, die erforderlich sind, damit die Implementierung die vom Servlet 3.1 Technology Compatibility Kit (TCK) ausgeführten Tests besteht.
  • Änderungen zur Verbesserung der Servletimplementierung.

Programmgesteuerte Konfiguration von Servlets, Filtern und Listenern

Aufgrund einer Präzisierung in der Servlet 3.1-Spezifikation ist die programmgesteuerte Konfiguration von Servlets, Filtern oder Listenern durch den ServletContextListener unzulässig, wenn der ServletContextListener nicht in der Datei web.xml oder in der Datei web-fragment.xml deklariert bzw. mit @WebListener annotiert wurde. Folglich wird bei jedem Versuch, mit ServletContext eine solche programmgesteuerte Konfiguration durchzuführen, eine Ausnahme des Typs UnsupportedOperationException zurückgegeben.

Weiterleitung nach dem Start einer asynchronen Verarbeitung

In der Servlet 3.0-Implementierung wird eine Antwort immer geschlossen, bevor die Weiterleitungsmethode der RequestDispatcher-Schnittstelle zurückkehrt. Aufgrund einer Präzisierung in der Servlet 3.1-Spezifikation wird aber bei einer Anforderung im asynchronen Modus die Antwort in der Servlet 3.1-Implementierung nicht geschlossen bzw. es wird keine Flushoperation ausgeführt, bevor die Weiterleitungsmethode der RequestDispatcher-Schnittstelle zurückkehrt. Diese Änderung kann sich auf Servlet 3.0-Anwendungen auswirken, die beim Zurückkehren der Weiterleitungsmethode Antwortdaten hinzufügen, weil diese Antwortdaten jetzt gesendet werden, in Servlet 3.0 jedoch nicht.

URL-Muster-Konflikt

In Servlet 3.0 wird eine Anwendung auch dann erfolgreich gestartet, wenn ein URL-Muster mehreren Servlets zugeordnet ist. Aufgrund einer Präzisierung in der Servlet 3.1-Spezifikation muss der Anwendungsstart fehlschlagen. In der Implementierung von Liberty Servlet 3.1 wird eine Nachricht ausgegeben und der Anwendungsstart schlägt fehl:
SRVE9016E: Die Zuordnung [{0}] für das Servlet [{1}] kann nicht eingefügt werden. Das URL-Muster ist bereits für das Servlet [{2}] definiert.

Erläuterung: Es liegt ein Anwendungsfehler vor. Ein URL-Muster für Servletzuordnung darf nicht mehreren Servlets entsprechen.

Benutzeraktion: Ändern Sie das URL-Muster für die Servletzuordnung.

ServletContext.getMinorVersion()

In der Implementierung des Features Servlet 3.0 gibt diese API 0 zurück.

Im Feature Servlet 3.1 gibt diese API jetzt 1 zurück.

ServletContext.getServerInfo()

In der Implementierung des Features Servlet 3.0 gibt diese API SMF WebContainer zurück.

Im Feature Servlet 3.1 gibt diese API jetzt IBM WebSphere Liberty/8.5.5.<x> zurück, wobei <x> die Nummer des WebSphere Application Server-Fixpacks ist.

ServletResponse.reset()

Sie können ServletResponse.reset() verwenden, um gepufferte Antwortdaten, den Statuscode und die Antwortheader zu löschen, wenn eine Antwort noch nicht festgeschrieben ist. Bei Verwendung des Features Servlet 3.1 löscht diese Methode auch alle Datensätze aus zuvor aufgerufenen ServletResonse.getWriter()- oder ServletResponse.getOutputStream()-Methoden.

X-Powered-By-Header

In der Implementierung des Features Servlet 3.0 wird der X-Powered-By-Header auf Servlet/3.0 gesetzt. In der Implementierung des Features Servlet 3.1 wird der X-Powered-By-Header auf Servlet/3.1 gesetzt.

Zusammenführung der Ressourcenreferenz-Injektionsziele

In der Servlet 3.0-Spezifikation werden die Elemente des Typs <injection-target> einer Ressourcenreferenz, die in einer web-fragment.xml-Datei definiert ist, nur dann zur übergeordneten web.xml-Datei hinzugefügt, wenn die web.xml-Ressourcenreferenzdefinition mit demselben Namen keine Elemente des Typs <injection-target> enthält. In der Servlet 3.1-Spezifikation wird präzisiert, dass für eine Ressourcenreferenz mit demselben Namen alle Elemente des Typs <injection-target> in den web-fragment.xml-Deskriptoren zur übergeordneten web.xml-Deskriptorliste der <injection-target>-Elemente hinzugefügt werden. Wenn das Feature Servlet 3.1 verwendet wird, kann es die bestehende Anwendungsfunktion ändern, indem es Injektionsziele aktiviert, die vorher aus der Datei web.xml ausgeschlossen waren.

Toleranz mehrerer Elemente in Webdeskriptoren

In der Spezifikation Servlet 3.1 wurde präzisiert, dass die Datei web.xml keine zwei Elemente des Typs <absolute-ordering> enthalten darf. Die Implementierung einer Anwendung mit mehreren <absolute-ordering>-Elementen schlägt fehl. Außerdem ist es nicht möglich, dass Deskriptoren des Typs web-fragment.xml zwei <ordering>-Elemente enthalten. Die Implementierung einer Anwendung mit mehreren <ordering>-Elementen schlägt fehl. Vorher schlug die Implementierung nicht fehl, aber die Funktion der Elemente war eventuell unbestimmt.

Änderung bezüglich der Webfragmentierung für "ordering"-Elemente bei Vorliegen von "metadata-complete"

Die Verarbeitung des Elements <absolute-ordering> hat sich für die Fälle, in denen ein Deskriptor des Typs web.xml als metadata-complete="true" gekennzeichnet ist, geändert. Vorher wurden im Fall von metadata-complete="true" alle Webfragmentarchive verwendet. Bei Verwendung des Features Servlet-3.1 wird das Element <absolute-ordering> bei Vorliegen von "metadata-complete" als vollständig betrachtet. Diese Änderung führt dazu, dass Fragmente, die nicht im Element <absolute-ordering> aufgelistet sind, von der Verarbeitung ausgeschlossen werden.

AsyncContext.dispatch()

Wenn AsyncContext.dispatch() verwendet wird (beispielsweise ohne Parameter), wird die Anforderung der ursprünglichen URL zugeteilt. Wenn das Feature Servlet-3.0 verwendet wird und wenn in die ursprüngliche Anforderung eine Abfragezeichenfolge aufgenommen wurde, wird diese für die zugeteilte Ressource verfügbar. Wenn jedoch das Feature Servlet 3.1 verwendet wird und wenn eine Abfragezeichenfolge für die Zuteilungsressource bereitgestellt wird, wird diese Abfragezeichenfolge für die zugeteilte Ressource verfügbar. Beispiel:
Request for /FirstResource?param=One
First Resource:
    getParameter("param") returns "One"
           forward request to /SecondResource?param=Two
SecondResource
           getParameter(param) returns "Two"
           ac.start()
           ac.dispacth() dispatches to /FirstResource
First Resource
           Servlet-3.0 feature : getParamter("param") returns "One"
           Servlet-3.1 feature : getParameter("param") returns "Two"

This change was required by the Servlet 3.1 TCK.
Das Abrufen des Anforderungs- oder Antwortobjekts nach der Ausführung einer Methode AsyncContext.dispatch() oder AsyncContext.complete() ist nicht zulässig und verursacht die folgende Ausnahme:
java.lang.IllegalStateException: SRVE9015E: Das Anforderungs- oder Antwortobjekt kann nach der Ausführung einer Methode
AsyncContext.dispatch() oder AsyncContext.complete() nicht abgerufen werden.
    at com.ibm.ws.webcontainer31.async.AsyncContext31Impl.getRequest(AsyncContext31Impl.java:72)
    [...]

SessionCookieConfig.setComment()

Gemäß der Spezifikation Java™ Servlet 3.1 gibt diese API eine Ausnahme des Typs illegalStateException zurück, wenn sie aufgerufen wird, nachdem der ServletContext die Initialisierung durchgeführt hat. Das Feature Servlet 3.1 folgt diesem erforderlichen Verhalten. Das Feature Servlet 3.0 verhindert jedoch nicht, dass diese API nach der Kontextinitialisierung verwendet wird, was dazu führt, dass Anwendungen, die vom Verhalten des Features Servlet 3.0 abhängig sind, mit dem Feature Servlet 3.1 nicht funktionieren.

API sendRedirect(java.lang.String location)

Die API sendRedirect(java.lang.String location) akzeptiert relative URLs. Allerdings muss der Servlet-Container die relative URL in eine absolute URL konvertieren, bevor er die Antwort an den Client senden kann. Wenn eine relative Position ohne vorangestellten Schrägstrich '/' verwendet wird (folder/default.jsp), interpretiert der Container sie als relativ zur aktuellen Anforderungs-URL. Wenn eine relative Position mit einem vorangestellten Schrägstrich '/' verwendet wird, interpretiert sie der Container als relativ zum Servlet-Container-Stammverzeichnis.

Beispiel: Wenn die Anwendung die Umleitungsposition folder/default.jsp ohne vorangestellten Schrägstrich '/' angibt und wenn die ankommende Anforderungs-URL http://host:port/context_root/folder oder http://host:port/context_root/folder/ lautet, wird die Anforderung an http://host:port/context_root/folder/folder/default.jsp umgeleitet, eine Position, die relativ zur aktuellen Anforderungs-URI ist.

Dieses Verhalten tritt im Feature Servlet 3.0 auf, wenn die Eigenschaft com.ibm.ws.webcontainer.redirectwithpathinfo auf true gesetzt ist. Im Feature Servlet 3.1 wird diese Eigenschaft ignoriert und es findet das beschriebene Standardverhalten statt.

Standardfehlerseiten

Die von IBM® erweiterte Funktion bietet die Möglichkeit, eine Standardfehlerseite mit einer Weberweiterung wie ibm-web-ext.xml festzulegen.

Als Funktion in Servlet 3.0 und höher stellen die Standardfehlerseiten eine Modifikation der Funktionalität zum Festlegen von Fehlerseiten dar. Wie bei normalen (Nicht-Standard-) Fehlerseiten werden auch die Standardfehlerseiten in Webmoduldeskriptoren (web.xml) und in Webfragmentdeskriptoren (web-fragment.xml) angegeben.

Normale (Nicht-Standard-) Fehlerseiten legen entweder einen Ausnahmetyp (exception-type) fest oder einen Fehlercode (error-code). In einer Standardfehlerseite sind weder "exception-type" noch "error-code" angegeben. Eine Standardfehlerseite wird verwendet, wenn ein Servlet eine Ausnahme auslöst oder ein Fehlercodeergebnis festlegt und keine konfigurierte Fehlerseite mit diesem Ausnahmetyp oder mit diesem festgelegten Fehlercode übereinstimmt.

Die Möglichkeit, Standardfehlerseiten zu definieren, wird von der Servlet 3.0-Spezifikation bereitgestellt und von den Servlet 3.0-Schemas unterstützt. Standardfehlerseiten sind Fehlerseiten, die gemäß der Servlet 3.1-Spezifikation kein Element des Typs exception-type oder error-code enthalten.

Nachfolgend sind Beispiele für Fehlerseiten und Standardfehlerseiten aufgeführt.

Regeln für die Rangfolge der Standardfehlerseiten
Um die Rangfolge der Standardfehlerseiten in den Dateien web.xml, web-fragment.xml und ibm-web-ext.xml festzulegen, werden drei Regeln angewendet.
  • Regel 1: Dateien web.xml und web-fragment.xml.

    Wenn eine Standardfehlerseite in der Datei web.xml angegeben ist, überschreibt (maskiert) diese jede in der Datei web-fragment.xml angegebene Standardfehlerseite. Außerdem können Standardfehlerseiten in mehreren web-fragment.xml-Dateien angegeben werden, ohne dass dies eine Fehlerbedingung ist.

  • Regel 2: web-fragment.xml und web-fragment.xml.

    Wenn in der Datei web.xml keine Standardfehlerseite angegeben ist und wenn in zwei oder mehr web-fragment.xml-Dateien unterschiedliche Standardfehlerseiten angegeben sind, liegt eine Fehlerbedingung vor.

  • Regel 3: Dateien ibm-web-ext.xml und web.xml oder web-fragment.xml.

    Die Regel zur Rangfolge der Datei ibm-web-ext.xml und der Datei web.xml oder der Datei web-fragment.xml ist abhängig von der Feature-Version des Web-Containers.

Wenn der Web-Container die Feature-Version 3.0 verwendet, hat eine in der Datei ibm-web-ext.xml definierte Standardfehlerseite Vorrang vor einer in der Datei web.xml oder web-fragment.xml definierten Datei.
Anmerkung: Wenn der Web-Container die Feature-Version 3.0 verwendet, können Sie keine Servlet 3.1-Schemas verwenden. Sehen Sie sich in diesem Fall die Regel zur Verwendung von Standardfehlerseiten an, die für Servlet 3.0-Schemas gilt.

Wenn der Web-Container die Feature-Version 3.1 verwendet, hat eine in der Datei web.xml oder web-fragment.xml angegebene Standardfehlerseite Vorrang vor einer in der Datei ibm-web-ext.xml angegebenen Standardfehlerseite.

Schemaregeln

Für die Festlegung, ob Standardfehlerseiten in der Datei web.xml oder in der Datei web-fragment.xml verarbeitet werden, gelten zwei Regeln. Die Regeln sind abhängig von der Feature-Version des Web-Containers, von dem verwendeten Servlet-Schema und von der Einstellung einer angepassten Java-Eigenschaft.

Diese Regeln wurden festgelegt, weil IBM WebSphere Application Server Traditional Version 8.0 im allgemein verfügbaren Release der Version 8.0 keine Standardfehlerseiten unterstützt hat. Die Unterstützung von Standardfehlerseiten wurde mit dem Service-Pack APAR PM94199 zu WebSphere Application Server Traditional hinzugefügt. Zu WebSphere Application Server Liberty wurde die Unterstützung für Standardfehlerseiten mit dem Service-Pack APAR PI05845 hinzugefügt. Weil diese Aktualisierungen eine Änderung einer extern sichtbaren Funktion darstellen, ist die neue Funktion standardmäßig inaktiviert und muss mit einer Java-Systemeigenschaft aktiviert werden.

  • Regel 1: Standardfehlerseiten mit Verwendung des Servlet 3.0-Schemas und der Feature-Version 3.0 des Web-Containers

    Wenn der Web-Container die Feature-Version 3.0 verwendet und eine Standardfehlerseite in den Dateien web.xml oder web-fragment.xml angegeben ist, die ein Servlet 3.0-Schema verwenden, werden die Standardfehlerseiten nur dann verarbeitet, wenn die Java-Systemeigenschaft com.ibm.ws.webcontainer.allowdefaulterrorpage auf true gesetzt ist. Wenn die Java-Systemeigenschaft nicht festgelegt ist oder nicht auf true gesetzt ist, wird die Standardfehlerseite ignoriert. Eine in der Datei ibm-web-ext.xml festgelegte Standardfehlerseite wird verwendet.

  • Fall 2: Standardfehlerseiten mit Verwendung der Feature-Version 3.1 des Web-Containers

    Wenn der Web-Container die Feature-Version 3.1 oder höher verwendet, wird eine in der Datei web.xml oder in der Datei web-fragment.xml angegebene Standardfehlerseite immer verarbeitet, unabhängig davon, welche Servletschemaversion verwendet wird und ob die angepasste Java-Eigenschaft festgelegt wurde.

    Dieser Fall liegt vor, wenn ein Deskriptor ein Servlet 3.1-Schema verwendet, da die Verarbeitung eines Deskriptors, der ein Servlet 3.1-Schema verwendet, voraussetzt, dass der Web-Container Feature-Version 3.1 verwendet.

Achtung: Webfragmente wurden erst in Servlet 3.0 hinzugefügt. Die Datei web-fragment.xml hat kein Schema aus Servlet 2.5.
Beispiele für die Fehlerseite und die Standardfehlerseite
Eine in der Datei ibm-web-ext.xml definierte Standardfehlerseite:
<?xml version="1.0" encoding="UTF-8"?>
<web-ext xmlns="http://websphere.ibm.com/xml/ns/javaee"
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-ext_1_0.xsd"
    version="1.0">

	<default-error-page uri="/ExtErrorPage.html"/>
</web-ext>
Ein in der Datei web.xml oder in der Datei web-fragment.xml definiertes "error-code"-Fehlerseitenelement:
<error-page>
		<error-code>404</error-code>
			<location>/ErrorCodeErrorPage.html</location>
</error-page>
Ein in der Datei web.xml oder in der Datei web-fragment.xml definiertes "exception-type"-Fehlerseitenelement:
<error-page>
		<exception-type>javax.servlet.ServletException</exception-type>
		<location>/ExceptionTypeErrorPage.html</location>
</error-page>
Ein in der Datei web.xml oder in der Datei web-fragment.xml definiertes Standardfehlerseitenelement:
<error-page>
		<location>/DefaultErrorPage.html</location>
</error-page>
Schemabeispiele
Beispielheader einer web.xml-Datei, die ein Servlet 2.5-Schema verwendet:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
		 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
      version="2.5">
Beispielheader einer web.xml-Datei, die ein Servlet 3.0-Schema verwendet:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
      version="3.0">
Beispielheader einer web.xml-Datei, die ein Servlet 3.1-Schema verwendet:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
    version="3.1">
Beispielheader einer web-fragment.xml-Datei, die ein Servlet 3.0-Schema verwendet:
<?xml version="1.0" encoding="utf-8"?>
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
      version="3.0">
Beispielheader einer web-fragment.xml-Datei, die ein Servlet 3.1-Schema verwendet:
<?xml version="1.0" encoding="utf-8"?>
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-fragment_3_1.xsd"
      version="3.1">

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_servlet_behavior
Dateiname:cweb_servlet_behavior.html