Verhaltensänderungen bei Servlet 3.1

Die Servlet 3.1-Implementierung weist Verhaltensänderungen auf, die dazu führen können, dass eine Anwendung, die für Servlet 3.0 geschrieben wurde, ein anderes Verhalten aufweist oder Fehler generiert, wenn Sie das Feature Servlet 3.1 verwenden.

Sie können für jede Serverinstanz festlegen, ob das Feature Servlet 3.0 oder das Feature Servlet 3.1 implementiert werden soll. Sie müssen jedoch Verhaltensunterschiede berücksichtigen. Wenn das erforderliche Verhalten nur im Feature Servlet 3.1 enthalten ist, müssen Sie das Feature Servlet 3.1 verwenden. Wenn sich Verhaltensunterschiede im Feature Servlet 3.1 auf eine vorhandene Anwendung nachteilig auswirken, verwenden Sie das Feature Servlet 3.0, um das vorhandene Verhalten für diese Anwendung beizubehalten. Es ist nicht möglich, das Feature Servlet 3.0 und das Feature Servlet 3.1 auf demselben Server zu verwenden. Beide Features zu konfigurieren ist ein Fehler. Wenn das geschieht, wird keines der beiden Servlet-Features geladen.

Die Verhaltensänderungen erfolgten aus drei Gründen:
  • Änderungen, die aufgrund von Klarstellungen in der Servlet 3.1-Spezifikation erforderlich wurden.
  • Änderungen, die Voraussetzung dafür sind, dass die Servlet 3.1-Implementierung das Servlet 3.1 Technology Compatibility Kit (TCK) übergeben kann.
  • Änderungen zur Verbesserung der Servletimplementierung.

Über das Programm hinzugefügte Servlets, Filter und Listener

Aufgrund einer Klarstellung in der Servlet 3.1-Spezifikation ist es jetzt unzulässig, dass ein ServletContextListener Servlets, Filter oder Listener über das Programm konfiguriert, falls der ServletContextListener nicht in der Datei web.xml bzw. web-fragment.xml deklariert oder nicht mit @WebListener annotiert wurde. Folglich löst jeder Aufruf des ServletContext mit dem Zweck, eine solche programmgesteuerte Konfiguration durchzuführen, eine Ausnahme vom Typ "UnsupportedOperationException" aus.

Weiterleitung nach Start von asynchroner Verarbeitung

In der Servlet 3.0-Implementierung wird eine Antwort immer geschlossen, bevor die Weiterleitungsmethode der RequestDispatcher-Schnittstelle Daten zurückgibt. Doch aufgrund einer Klarstellung in der Servlet 3.1-Spezifikation wird die Antwort von der Servlet 3.1-Implementierung nicht geschlossen bzw. auf Platte geschrieben, bevor die Weiterleitungsmethode Daten der RequestDispatcher-Schnittstelle zurückgibt, wenn die Anforderung in den asynchronen Modus versetzt wird. Diese Änderung kann sich auf vorhandene Anwendungen der Version 3.0 auswirken, die bei der Rückgabe von Daten der Weiterleitungsmethode Antwortausgabe hinzufügen, weil solche Antwortdaten im Gegensatz zu Servlet 3.0 jetzt gesendet werden.

Überschneidungen von URL-Mustern

In Servlet 3.0 wird eine Anwendung auch dann erfolgreich gestartet, wenn ein URL-Muster mehreren Servlets zugeordnet wird. Aufgrund einer Klarstellung in der Servlet 3.1-Spezifikation muss der Start der Anwendung jedoch fehlschlagen. In der Servlet 3.1-Implementierung in Liberty wird eine Nachricht ausgegeben und die Anwendung kann nicht gestartet werden:
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 die Servletzuordnung darf nicht mehreren Servlets zugeordnet werden. 
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 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. <x> steht dabei für die Nummer des WebSphere Application Server-Fixpacks.

ServletResponse.reset()

Sie können ServletResponse.reset() verwenden, um gepufferte Antwortdaten, den Statuscode und Antwortheader zu löschen, wenn noch keine Antwort festgeschrieben wurde. Wird das Feature Servlet 3.1 verwendet, löscht diese Methode auch alle Datensätze von ServletResonse.getWriter() oder ServletResponse.getOutputStream(), die zuvor aufgerufen wurden.

X-Powered-By-Header

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

Zusammenführung der Injektionsziele von Ressourcenreferenzen

In der Servlet 3.0-Spezifikation werden die <injection-target>-Elemente einer in der Datei web-fragment.xml definierten Ressourcenreferenz der übergeordneten Datei web.xml nur dann hinzugefügt, wenn die Ressourcenreferenzdefinition von web.xml mit demselben Namen keine <injection-target>-Elemente hat. In der Servlet 3.1-Spezifikation wird klargestellt, dass alle <injection-target>-Elemente in Deskriptoren des Typs web-fragment.xml der Liste der übergeordneten Deskriptoren des Typs web.xml von <injection-target>-Elementen für eine Ressourcenreferenz desselben Namens hinzugefügt werden. Wenn das Feature Servlet 3.1 im Gebrauch ist, kann es vorhandene Anwendungsfunktionen ändern, indem es Injektionsziele, die zuvor aus der Datei web.xml ausgeschlossen wurden, aktiviert.

Toleranz von doppelt vorhandenen Elementen in Webdeskriptoren

In der Servlet 3.1-Spezifikation wurde klargestellt, dass eine Datei des Typs web.xml nicht zwei <absolute-ordering>-Elemente enthalten kann. Die Implementierung einer Anwendung mit mehreren <absolute-ordering>-Elementen schlägt fehl. Außerdem können Deskriptoren des Typs web-fragment.xml nicht zwei <ordering>-Elemente enthalten. Die Implementierung einer Anwendung mit mehreren <ordering>-Elementen schlägt fehl. Zuvor schlug die Implementierung zwar nicht fehl, die Funktion der Elemente konnte aber unbestimmt sein.

Änderung bei der Anordnung von Webfragmenten in Fällen mit metadata-complete

Die Verarbeitung des <absolute-ordering>-Elements wurde in den Fällen, in denen ein Deskriptor des Typs web.xml die Markierung metadata-complete="true" hat, geändert. Früher wurden bei Verwendung von metadata-complete="true" alle Webfragmentarchive verwendet. Wenn das Feature Servlet-3.1 verwendet wird, gilt das Element <absolute-ordering> in Fällen mit metadata-complete als vollständig. Diese Änderung führt dazu, dass Fragmente, die nicht im Element <absolute-ordering> aufgelistet sind, aus der Verarbeitung ausgeschlossen werden.

AsyncContext.dispatch()

Wenn AsyncContext.dispatch() verwendet wird (beispielsweise ohne Parameter), wird die Anforderung der ursprünglichen URL zugeteilt. Wird bei Verwendung des Features Servlet-3.0 eine Abfragezeichenfolge mit der ursprünglichen Anforderung eingeschlossen, wird diese Abfragezeichenfolge der zugeteilten Ressource zugänglich gemacht. Wird der zuteilenden Ressource bei Verwendung des Features Servlet 3.1 eine Abfragezeichenfolge bereitgestellt, wird diese Abfragezeichenfolge der zugeteilten Ressource zugänglich gemacht. 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 von AsyncContext.dispatch() oder AsyncContext.complete() ist nicht zulässig und führt dazu, dass die folgende Ausnahme ausgelöst wird:
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 Java™ Servlet 3.1-Spezifikation gibt diese API eine Ausnahme vom Typ "illegalStateException" zurück, wenn sie nach der Initialisierung von ServletContext aufgerufen wurde. Das Feature Servlet 3.1 folgt diesem erforderlichen Verhalten. Das Feature Servlet 3.0 verhindert nicht die Verwendung dieser API nach der Kontextinitialisierung, und daher funktionieren Anwendungen, die vom Verhalten des Features Servlet 3.0 abhängig sind, nicht mit dem Feature Servlet 3.1.

API sendRedirect(java.lang.String location)

Die API sendRedirect(java.lang.String location) akzeptiert zwar relative URLs, doch der Servlet-Container muss die relative URL in eine absolute URL konvertieren, bevor die Antwort an den Client gesendet werden kann. Wenn eine relative Position ohne führenden Schrägstrich "/" angegeben wird (folder/default.jsp), interpretiert der Container die Angabe als relativ zum aktuellen Anforderungs-URI. Wenn die Position relativ mit führendem Schrägstrich ("/") angegeben wird, interpretiert der Container die Angabe als relativ zum Stammverzeichnis des Servlet-Containers.

Wenn beispielsweise die von der Anwendung bereitgestellte Umleitungsposition folder/default.jsp ist, keinen führenden Schrägstrich "/" hat und die eingehende Anforderungs-URL http://Host:Port/Kontextstammverzeichnis/folder bzw. http://Host:Port/Kontextstammverzeichnis/folder/ lautet, wird die Anforderung zur Position http://Host:Port/Kontextstammverzeichnis/folder/folder/default.jsp umgeleitet, relativ zum aktuellen Anforderungs-URI.

Dieses Verhalten findet sich im Feature Servlet 3.0, wenn die Eigenschaft com.ibm.ws.webcontainer.redirectwithpathinfo auf true gesetzt ist. Diese Eigenschaft wird im Feature Servlet 3.1 und in den Standardeinstellungen für das Verhalten ignoriert, wie beschrieben.

Standardfehlerseiten

Die erweiterte IBM® Funktion ist die Fähigkeit, eine Standardfehlerseite mit einer Weberweiterung anzugeben, wie z. B. ibm-web-ext.xml.

Als Funktion von Servlet 3.0 und höher bedeuten Standardfehlerseiten eine Änderung der Funktionalität zur Angabe von Fehlerseiten. Standardfehlerseiten werden wie normale (vom Standard abweichende) Fehlerseiten in Webmoduldeskriptoren (web.xml) und in Webfragmentdeskriptoren (web-fragment.xml) angegeben.

Normale (vom Standard abweichende) Fehlerseiten geben entweder einen Ausnahmetyp (exception-type) oder einen Fehlercode (error-code) an. Eine Standardfehlerseite schließt sowohl den Ausnahmetyp als auch den Fehlercode aus. Eine Standardfehlerseite wird verwendet, wenn ein Servlet eine Ausnahmebedingung auslöst oder ein Fehlercodeergebnis festlegt und keine konfigurierte Fehlerseite mit dem Typ der Ausnahme oder dem festgelegten Fehlercode übereinstimmt.

Die Funktionalität zum Definieren von Standardfehlerseiten wird von der Servlet 3.0-Spezifikation bereitgestellt und von den Servlet 3.0-Schemas unterstützt. Laut Servlet 3.1-Spezifikation sind Standardfehlerseiten Fehlerseiten, die kein exception-type- oder error-code-Element enthalten.

Im Folgenden finden Sie Beispiele für Fehlerseiten und Standardfehlerseiten:

Vorrangregeln für Standardfehlerseiten
Es gelten drei Regeln für die Bestimmung der Rangfolge von Standardfehlerseiten in den Dateien web.xml, web-fragment.xml und ibm-web-ext.xml.
  • Regel 1: Datei web.xml und Datei web-fragment.xml.

    Wenn eine Standardfehlerseite in der Datei web.xml angegeben wird, überschreibt (maskiert) sie jede Standardfehlerseite, die in einer Datei des Typs web-fragment.xml angegeben ist. Es liegt kein Fehler vor, wenn mehrere Dateien des Typs web-fragment.xml Standardfehlerseiten angeben.

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

    Wird eine Standardfehlerseite nicht in der Datei web.xml angegeben, liegt eine Fehlerbedingung vor, wenn verschiedene Standardfehlerseiten von zwei oder mehr Dateien des Typs web-fragment.xml angegeben werden.

  • Regel 3: Datei ibm-web-ext.xml und Datei web.xml bzw. web-fragment.xml.

    Die Rangfolgenregel für die Datei ibm-web-ext.xml und die Datei web.xml bzw. web-fragment.xml hängt von der Featureversion des Web-Containers ab.

Wenn die Featureversion des Web-Containers 3.0 ist, hat eine Standardfehlerseite, die in einer Datei des Typs ibm-web-ext.xml definiert ist, Vorrang vor einer Standardfehlerseite, die in einer Datei des Typs web.xml oder web-fragment.xml definiert ist.
Anmerkung: Verwendet der Web-Container die Featureversion 3.0, können Sie keine Servlet 3.1-Schemas verwenden. Wenden Sie die Regel zur Verwendung von Standardfehlerseiten für Servlet 3.0-Schemas an.

Wenn der Web-Container die Featureversion 3.1 oder höher verwendet, hat eine Standardfehlerseite, die in einer Datei des Typs web.xml oder web-fragment.xml definiert ist, Vorrang vor einer Standardfehlerseite, die in einer Datei des Typs ibm-web-ext.xml definiert ist.

Schemaregeln

Es gibt zwei Regeln, mit denen bestimmt wird, ob Standardfehlerseiten in Dateien des Typs web.xml oder web-fragment.xml verarbeitet werden. Die Regeln hängen davon ab, welche Featureversion der Web-Container verwendet, welches Servletschema im Gebrauch ist und welche Einstellung einer angepassten Java-Eigenschaft aktiv ist.

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

  • Regel 1: Standardfehlerseiten, die das Servlet 3.0-Schema und die Featureversion 3.0 des Web-Containers verwenden

    Wird der Web-Container die Featureversion 3.0 verwendet und ist eine Standardfehlerseite in einer Datei des Typs web.xml oder web-fragment.xml angegeben, die ein Servlet 3.0-Schema verwendet, werden die Standardfehlerseiten nur verarbeitet, wenn die Java-Systemeigenschaft com.ibm.ws.webcontainer.allowdefaulterrorpage auf true gesetzt ist. Wenn die Java-Systemeigenschaft nicht festgelegt oder nicht auf true gesetzt ist, wird die Standardfehlerseite ignoriert. Es wird dann eine Standardfehlerseite verwendet, die in der Datei ibm-web-ext.xml angegeben ist.

  • Fall 2: Standardfehlerseiten bei Verwendung der Web-Container-Feature-Version 3.1

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

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

Achtung: Webfragmente wurden erst ab Servlet 3.0 hinzugefügt. Die Datei web-fragment.xml hat kein Schema aus Servlet 2.5.
Beispiele für Fehlerseiten und Standardfehlerseiten
Eine Standardfehlerseite, die in einer Datei des Typs ibm-web-ext.xml definiert ist:
<?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 Fehlerseitenelement des Typs "error-code", das in der Datei web.xml oder web-fragment.xml definiert ist:
<error-page>
		<error-code>404</error-code>
			<location>/ErrorCodeErrorPage.html</location>
</error-page>
Ein Fehlerseitenelement des Typs "exception-type", das in der Datei web.xml oder web-fragment.xml definiert ist:
<error-page>
		<exception-type>javax.servlet.ServletException</exception-type>
		<location>/ExceptionTypeErrorPage.html</location>
</error-page>
Ein Standardfehlerseitenelement, das in der Datei web.xml oder web-fragment.xml definiert ist:
<error-page>
		<location>/DefaultErrorPage.html</location>
</error-page>
Schemabeispiele
Beispielheader einer Datei des Typs web.xml, 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 Datei des Typs web.xml, 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 Datei des Typs web.xml, 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 Datei des Typs web-fragment.xml, 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 Datei des Typs web-fragment.xml, 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: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_servlet31_behavior
Dateiname: cwlp_servlet31_behavior.html