Verhaltensänderungen bei Servlet 3.1
Die Servlet 3.1-Implementierung beinhaltet Verhaltensänderungen, die dazu führen können, dass eine Anwendung, die für Servlet 3.0 geschrieben wurde, fehlschlägt, 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.
- Ä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 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
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.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 belegt 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 aberunbestimmt sein.
Änderung bei der Anordnung von Webfragmenten in Fällen des Typs 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 des Typs "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()
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.
SessionCookieConfig.setComment()
Gemäß der Java™ Servlet 3.1-Spezifikation gibt diese API eine 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 Eigenschaftcom.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.
Beispiele für Fehlerseiten und Standardfehlerseiten folgen.
- 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.
Wenn eine Standardfehlerseite nicht in der Datei web.xml angegeben wird, 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 Feature-Version des Web-Containers ab.
Wenn die Feature-Version 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 Feature-Version 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 Feature-Version 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.
- Regel 1: Datei web.xml und Datei web-fragment.xml.
- Schemaregeln
Es gibt zwei Regeln, mit denen bestimmt, ob Standardfehlerseiten in Dateien des Typs web.xml oder web-fragment.xml verarbeitet werden. Die Regeln hängen davon ab, welche Feature-Version der Web-Container verwendet, welches Servlet-Schema genutzt wird und welche Einstellung einer angepasstenJava-Eigenschaft aktiv ist.
Diese Regeln wurden geschaffen, weil das vollständige IBM WebSphere Application Server V8.0-Profil im allgemein verfügbaren Release V8.0 keine Standardfehlerseiten unterstützte. Die Unterstützung für Standardfehlerseiten wurde dem vollständigen Application Server-Profil im Rahmen eines Service-Packs durch APAR PM94199 hinzugefügt. Dem Liberty-Profil von Application Server 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 Feature-Version 3.0 des Web-Containers verwenden
Wenn der Web-Container Feature-Version 3.0 verwendet und eine Standardfehlerseite in einer Datei des Typs web.xml oder web-fragment.xml angegeben ist, 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 Feature-Version 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 Servlet-Schemaversion 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.
- Regel 1: Standardfehlerseiten, die das Servlet 3.0-Schema und die Feature-Version 3.0 des Web-Containers verwenden
- 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">