Ä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.
- Ä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
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()
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.
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.
- Regel 1: Dateien web.xml und web-fragment.xml.
- 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.
- Regel 1: Standardfehlerseiten mit Verwendung
des Servlet 3.0-Schemas und der Feature-Version 3.0 des Web-Containers
- 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">