Cambios en el comportamiento de un servlet
La implementación de Servlet 3.1 contiene cambios de comportamiento que pueden provocar que una aplicación desarrollada para Servlet 3.0 se comporte de modo diferente o falle cuando se utilice la característica Servlet 3.1 .
En cada instancia de servlet se puede elegir entre implementaciones de características de Servlet 3.0 y Servlet 3.1, teniendo en cuenta los cambios de comportamiento. Si el comportamiento requerido solo se encuentra en la característica Servlet 3.1, habrá que utilizar dicha característica. Si una aplicación existente resultara negativamente afectada por los cambios de comportamiento en la característica Servlet 3.1, el uso de la característica Servlet 3.0 mantendrá el comportamiento de dicha aplicación. No es posible utilizar ambas características, Servlet 3.0 y Servlet 3.1, en el mismo servidor. Es un error configurar ambas características. Si se configuran ambas características, no se cargará ninguna característica de servlet.
- Cambios exigidos por aclaraciones en la especificación Servlet 3.1.
- Cambios necesarios para que la implementación pase el Servlet 3.1 Technology Compatibility Kit (TCK).
- Cambios para mejorar la implementación de servlet.
Servlets, filtros y escuchas añadidos programáticamente
Una aclaración de la especificación Servlet 3.1 hace que ahora sea ilegal que un ServletContextListener configure servlets, filtros o escuchas programáticamente si el ServletContextListener no se ha declarado en el archivo web.xml o en el archivo web-fragment.xml o no se ha anotado con @WebListener. Por tanto, cualquier llamada al ServletContext para realizar una configuración programática de este tipo dará lugar a una UnsupportedOperationException.
Reenvío (forward) después de iniciar el procesamiento asíncrono
En la implementación de Servlet 3.0, una respuesta siempre se cierra antes de que el método de reenvío de la interfaz RequestDispatcher efectúe el retorno. Sin embargo, debido a una aclaración en la especificación Servlet 3.1, la implementación de Servlet 3.1 no cierra ni vacía la respuesta antes de que el método de reenvío de la interfaz RequestDispatcher efectúe el retorno, si la petición se pone (put) en el modo asíncrono. Este cambio puede afectar a las aplicaciones 3.0 existentes, que añaden la salida de respuesta al retornar del reenvío, ya que ahora se envían estos datos de respuesta, mientras que en Servlet 3.0, no se enviaban.
Conflictos de patrón de URL
SRVE9016E: No se puede insertar
la correlación [{0}] para el servlet denominado [{1}]. El patrón de URL ya está definido para el servlet denominado [{2}].
Explicación: Existe un error de aplicación. Un patrón de URL de correlación de servlets no debe correlacionar con varios servlets.
Acción del usuario: Cambie el patrón de URL de la correlación de servlets.
ServletContext.getMinorVersion()
En la implementación de la característica Servlet 3.0, este API devuelve 0.
En la característica Servlet 3.1, este API ahora devuelve 1.
ServletContext.getServerInfo()
En la implementación de la característica Servlet 3.0, este API devuelve SMF WebContainer.
En la característica Servlet 3.1 este API ahora devuelve IBM WebSphere Liberty/8.5.5.<x>, donde <x> es el número de fixpack de WebSphere Application Server.
ServletResponse.reset()
ServletResponse.reset() se puede usar para borrar cualquier dato de respuesta guardado en búfer, el código de estado y las cabeceras de respuesta cuando todavía no se ha confirmado una respuesta. Si se utiliza la característica Servlet 3.1, este método también borra cualquier registro de ServletResonse.getWriter() o ServletResponse.getOutputStream() invocados previamente.
Cabecera X-Powered-By
En la implementación de características de Servlet 3.0, la cabecera X-Powered-By se establece a Servlet/3.0. En la implementación características de Servlet 3.1, la cabecera X-Powered-By se establece a Servlet/3.1.
Fusión de destinos de inyección de referencia de recursos
En la especificación Servlet 3.0, los elementos <injection-target> de una referencia de recursos definida en un archivo web-fragment.xml solo se añaden al archivo padre web.xml si la definición de referencia de recursos de web.xml con el mismo nombre no tiene ningún elemento <injection-target>. En la especificación Servlet 3.1, se clarifica que todos los elementos <injection-target> en descriptores de web-fragment.xml se añaden a la lista de descriptores de los elementos <injection-target> del web.xml padre para una referencia de recursos del mismo nombre. Si se utiliza la característica de Servlet 3.1, esta podría cambiar la función de aplicación existente activando destinos de inyección excluidos anteriormente del archivo web.xml.
Tolerancia de elementos duplicados en descriptores web
En la especificación Servlet 3.1, se ha clarificado que un archivo web.xml no puede contener dos elementos <absolute-ordering> . El despliegue de una aplicación con varios elementos <absolute-ordering> falla. Además, los descriptores de web-fragment.xml no pueden contener dos elementos <ordering>. El despliegue de una aplicación con varios elementos <ordering> falla. Anteriormente, el despliegue no fallaba, pero la función de los elementos podía ser indeterminada.
Cambio de orden de los fragmentos web en los casos de metadata-complete
El procesamiento del elemento <absolute-ordering> cambia en los casos donde un descriptor de web.xml se marca como metadata-complete="true". Anteriormente, en los casos metadata-complete="true", se utilizaban todos los archivados de fragmentos web. Cuando se utiliza la característica Servlet-3.1, el elemento <absolute-ordering> en los casos metadata-complete se considera completo. Este cambio da lugar a fragmentos que no se listan en el elemento <absolute-ordering> para ser excluidos del proceso.
AsyncContext.dispatch()
Petición dirigida a /PrimerRecurso?param=Uno
Primer recurso:
getParameter("param") devuelve "Uno"
se reenvía la petición a /RecursoSegundo?param=Dos
Segundo recurso
getParameter(param) devuelve "Dos"
ac.start()
ac.dispacth() entrega a /PrimerRecurso
Primer recurso
Característica Servlet-3.0 : getParamter("param") devuelve "Uno"
Característica Servlet-3.1 : getParameter("param") devuelve "Dos"
Este cambio es una exigencia del TCK de Servlet 3.1.
java.lang.IllegalStateException: SRVE9015E: No se puede obtener el objeto de solicitud o respuesta después de un AsyncContext.dispatch() o AsyncContext.complete().
en com.ibm.ws.webcontainer31.async.AsyncContext31Impl.getRequest(AsyncContext31Impl.java:72)
[...]
SessionCookieConfig.setComment()
Conforme a la especificación Java™ Servlet 3.1, esta API devuelve una illegalStateException si se invoca una vez completada la inicialización de ServletContext, y la característica Servlet 3.1 sigue este comportamiento obligatorio. Sin embargo, la característica de Servlet 3.0 no impide el uso de esta API una vez inicializado el contexto y, por tanto, las aplicaciones que dependen del comportamiento de la característica Servlet 3.0 no funcionarán con la característica Servlet 3.1.
API sendRedirect(java.lang.String ubicacion)
El API sendRedirect(java.lang.String ubicacion) acepta URL relativos. Sin embargo, el contenedor de servlets debe convertir el URL relativo en un URL absoluto para poder enviar la respuesta al cliente. Si la ubicación es relativa sin ir precedida de '/' (folder/default.jsp), el contenedor la interpreta como relativa al URI de la petición actual. Si la ubicación es relativa e incluye una barra inclinada inicial ('/'), el contenedor la interpreta como relativa a la raíz del contenedor de servlets.
Por ejemplo, si la ubicación de redirección que proporciona la aplicación es folder/default.jsp, sin la barra inclinada inicial '/', y el URL de la solicitud de entrada es http://host:puerto/raíz_contexto/carpeta o http://host:puerto/raíz_contexto/carpeta, la solicitud se redirige a http://host:puerto/raíz_contexto/carpeta/carpeta/default.jsp, la cual es relativa al URI de la solicitud actual.
Este comportamiento se da en la característica Servlet 3.0 cuando la propiedad com.ibm.ws.webcontainer.redirectwithpathinfo se establece a true. Esta propiedad se omite en la característica Servlet 3.1 y el comportamiento es el predeterminado, como se ha descrito.
Páginas de error predeterminadas
La función ampliada de IBM® consiste en la posibilidad de especificar una página de error predeterminada con una extensión web como, por ejemplo, ibm-web-ext.xml.
Como función de Servlet 3.0 y posteriores, las páginas de error predeterminadas son una modificación de la capacidad de especificar páginas de error. Al igual que las páginas de error normales (no predeterminadas), las páginas de error predeterminadas se especifican en los descriptores de módulo web (web.xml) y en los descriptores de fragmento web (web-fragment.xml).
Las páginas de error normales (no predeterminadas) especifican un tipo de excepción o un código de error. Una página de error predeterminada omite tanto el tipo de excepción como el código de error. Una página de error predeterminada se utiliza cuando un servlet lanza una excepción o establece un resultado de código de error y ninguna página de error configurada coincide con el tipo de la excepción o con el código de error definido.
La capacidad de definir páginas de error predeterminadas se proporciona en la especificación Servlet 3.0 y está soportada por los esquemas de Servlet 3.0. Las páginas de error predeterminadas son páginas de error que no contienen un elemento exception-type o error-code, según la especificación Servlet 3.1.
A continuación se proporcionan ejemplos de páginas de error y de páginas de error predeterminadas.
- Reglas de prioridad de una página de error predeterminada
- Se aplican tres reglas para determinar la prioridad de las páginas de error predeterminadas en los archivos web.xml,
web-fragment.xml y ibm-web-ext.xml.
- Regla 1: Archivos web.xml y web-fragment.xml.
Cuando se especifica una página de error predeterminada en el archivo web.xml, sustituye (enmascara) cualquier página de error predeterminada que se haya especificado en un archivo web-fragment.xml. Asimismo, no existe ningún error si, además, varios archivos web-fragment.xml especifican páginas de error predeterminadas.
- Regla 2: web-fragment.xml y web-fragment.xml.
Si no se especifica una página de error predeterminada en el archivo web.xml, se produce una condición de error si dos o más archivos web-fragment.xml especifican páginas de error predeterminadas diferentes.
- Regla 3: archivos ibm-web-ext.xml y web.xml o web-fragment.xml.
La regla de prioridad entre el archivo ibm-web-ext.xml y los archivos web.xml o web-fragment.xml depende del nivel de característica del contenedor web.
Si el nivel de característica del contenedor web es 3.0, una página de error predeterminada definida por un archivo ibm-web-ext.xml tendrá prioridad sobre una página de error predeterminada definida en los archivos web.xml o web-fragment.xml.Nota: Si el contenedor web utiliza el nivel de característica 3.0, no pueden utilizarse esquemas de Servlet 3.1. Consulte la regla sobre el uso de páginas de error predeterminadas para los esquemas de Servlet 3.0.Si el nivel de característica del contenedor web es 3.1 o superior, una página de error predeterminada especificada por el archivo web.xml o web-fragment.xml tendrá prioridad sobre una página de error predeterminada especificada en el archivo ibm-web-ext.xml.
- Regla 1: Archivos web.xml y web-fragment.xml.
- Reglas de esquema
Se aplican dos reglas para determinar si las páginas de error predeterminadas se procesan en los archivos web.xml o web-fragment.xml. Las reglas dependen de la versión de característica del contenedor web, del esquema de Servlet utilizado y del valor de una propiedad personalizada Java.
Estas reglas surgieron porque IBM WebSphere Application Server tradicional V8.0 no soportaba las páginas de error predeterminadas en el release de disponibilidad general de la V8.0. Se ha añadido soporte para las páginas de error predeterminadas en WebSphere Application Server tradicional, en un Service Pack, en el APAR PM94199. Se ha añadido soporte de páginas de error predeterminadas en WebSphere Application Server Liberty, en un Service Pack, en el APAR PI05845. Puesto que estas actualizaciones suponen un cambio en la función visible externamente, la nueva función está inhabilitada de forma predeterminada y debe habilitarse mediante una propiedad de sistema Java.
- Regla 1: Páginas de error predeterminadas al utilizar el esquema de Servlet 3.0 y la versión de característica de contenedor web 3.0.
Si la versión de la característica del contenedor web es 3.0 y se especifica una página de error predeterminada en archivos web.xml o web-fragment.xml que utilizan un esquema de Servlet 3.0, las páginas de error predeterminadas solo se procesarán si la propiedad de sistema Java com.ibm.ws.webcontainer.allowdefaulterrorpage se establece a true. Si la propiedad de sistema Java no está definida o no se ha establecido a true, la página de error predeterminada se ignorará. Se utiliza una página de error predeterminada especificada por el archivo ibm-web-ext.xml.
- Regla 2: Páginas de error predeterminadas al utilizar la versión de característica de contenedor web 3.1.
Si la versión de la característica de contenedor web es 3.1 o superior, siempre se procesará una página de error predeterminada especificada en los archivos web.xml o web-fragment.xml, independientemente de qué versión de esquema de servlet se utilice e independientemente de si se ha definido la propiedad personalizada Java.
Este caso se produce cuando un descriptor utiliza un esquema de Servlet 3.1, ya que el procesamiento de un descriptor que utiliza un esquema de Servlet 3.1 requiere la versión 3.1 de la característica de contenedor web.
- Regla 1: Páginas de error predeterminadas al utilizar el esquema de Servlet 3.0 y la versión de característica de contenedor web 3.0.
- Ejemplos de página de error y de página de error predeterminada
- Página de error predeterminada definida en un archivo ibm-web-ext.xml:
<?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>
- Elemento de página de error error-code, que se define en los archivos web.xml o web-fragment.xml:
<error-page> <error-code>404</error-code> <location>/ErrorCodeErrorPage.html</location> </error-page>
- Elemento de página de error exception-type, que se define en los archivos web.xml o web-fragment.xml:
<error-page> <exception-type>javax.servlet.ServletException</exception-type> <location>/ExceptionTypeErrorPage.html</location> </error-page>
- Elemento de página de error predeterminada, que se define en los archivos web.xml o web-fragment.xml:
<error-page> <location>/DefaultErrorPage.html</location> </error-page>
- Ejemplos de esquema
- Ejemplo de cabecera de un archivo web.xml que utiliza un esquema de Servlet 2.5:
<?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">
- Ejemplo de cabecera de un archivo web.xml que utiliza un esquema de Servlet 3.0:
<?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">
- Ejemplo de cabecera de un archivo web.xml que utiliza un esquema de Servlet 3.1:
<?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">
- Ejemplo de cabecera de un archivo web-fragment.xml que utiliza un esquema de Servlet 3.0:
<?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">
- Ejemplo de cabecera de un archivo web-fragment.xml que utiliza un esquema de Servlet 3.1:
<?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">