Cambios en el comportamiento de Servlet 3.1

La implementación de Servlet 3.1 contiene cambios de comportamiento que pueden provocar que una aplicación que se ha escrito para Servlet 3.0 se comporte de modo diferente o falle cuando se utiliza la característica Servlet 3.1.

Puede elegir entre las implementaciones de característica Servlet 3.0 y Servlet 3.1 para cada instancia de servidor, teniendo en cuenta los cambios de comportamiento. Si el comportamiento necesario sólo se encuentra en la característica Servlet 3.1, debe utilizar la característica Servlet 3.1. Si una aplicación existente resultaría negativamente afectada por los cambios de comportamiento de la característica Servlet 3.1, el uso de la característica Servlet 3.0 conservará el comportamiento existente de esa 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 configura ambas características, no se cargará ninguna característica de servlet.

Los cambios de comportamiento se han introducido por tres razones:
  • Cambios que son necesarios para aclaraciones de la especificación Servlet 3.1.
  • Cambios que son necesarios para la implementación de Servlet 3.1 para pasar el TCK (kit de compatibilidad de tecnología) Servlet 3.1.
  • Cambios para mejorar la implementación del servlet.

Servlets, filtros y escuchas añadidos por programa

Una aclaración de la especificación Servlet 3.1 hace ahora ilegal que un ServletContextListener configure servlets, filtros o escuchas por programa 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. Como resultado, cualquier llamada en el ServletContext para realizar una configuración programática de este tipo da como resultado una UnsupportedOperationException.

Reenvío después de iniciar el proceso 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 o desecha la respuesta antes de que el método de reenvío de la interfaz RequestDispatcher efectúe el retorno, si la petición se sitúa en la modalidad asíncrona. Este cambio puede afectar a las aplicaciones 3.0 existentes, que añaden la salida de respuesta en la devolución desde el 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

En Servlet 3.0, una aplicación se iniciará satisfactoriamente aunque un patrón de URL se haya correlacionado con varios servlets. Sin embargo, debido a una aclaración en la especificación Servlet 3.1, la aplicación no debe poder iniciarse. En la implementación de Liberty Profile Servlet 3.1, se genera un mensaje y la aplicación no puede iniciarse:
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 llamado [{2}].

Descripción: Existe un error de aplicación. Un patrón de URL de correlación de servlets no se debe correlacionar con varios servlets.

Acción del usuario: Cambie el patrón de URL para la correlación de servlets. 

ServletContext.getServerInfo()

En la implementación de la característica Servlet 3,0, esta API devuelve SMF WebContainer.

En la característica Servlet 3.1, esta API devuelve IBM WebSphere Liberty/8.5.5.<x>, donde <x> es el número de fixpack de WebSphere Application Server.

ServletResponse.reset()

Puede utilizar ServletResponse.reset() para borrar cualquier dato de respuesta del almacenamiento intermedio y las cabeceras de respuestas 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() invocado previamente.

Cabecera X-Powered-By

En la implementación de la característica Servlet 3.0, la cabecera X-Powered-By se establece en Servlet/3.0. En la implementación de la característica Servlet 3.1, la cabecera X-Powered-By se establece en 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 recurso definida en un archivo web-fragment.xml sólo se añaden al archivo web.xml padre si la definición de referencia de recurso de web.xml con el mismo nombre no tiene elementos <injection-target>. En la especificación Servlet 3.1, se clarifica que todos los elementos <injection-target> en descriptores web-fragment.xml se añaden a la lista de descriptores web.xml padre de los elementos <injection-target> para una referencia de recursos del mismo nombre. Si se utiliza la característica de Servlet 3.1, esta característica puede 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 aclaró 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 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 fragmentos web en los casos de metadata-complete

El proceso del elemento <absolute-ordering> cambia en los casos en los que un descriptor web.xml se marca como metadata-complete=“true". Anteriormente, en los casos metadata-complete="true", se utilizaban todos los archivos de fragmentos web. Cuando se utiliza la característica Servlet-3.1, el elemento <absolute-ordering> en los casos de metadata-complete se considera como completado. Este cambio provoca que los fragmentos que no aparecen en el elemento <absolute-ordering> se excluyan del proceso.

AsyncContext.dispatch()

Cuando se utiliza AsyncContext.dispatch(), por ejemplo, sin parámetros, la solicitud se entrega al URL original. En la característica Servlet-3.0, si se incluía una serie de consulta en la petición original, se ponía a disposición del recurso asignado. Sin embargo, si se utiliza la característica de Servlet 3.1, si se suministra una serie de consulta al recurso de asignación, es la serie de consulta la que se pone a disposición del recurso asignado. Por ejemplo:
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”

Este cambio era necesario para el TCK de Servlet 3.1. 

SessionCookieConfig.setComment()

De acuerdo con 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 Servlet-3.0 no impide el uso de esta API una vez inicializado el contexto y, como resultado, 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(ubicación java.lang.String)

La API sendRedirect(ubicación java.lang.String) 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 y no incluye una barra inclinada '/' inicial, (folder/default.jsp), el contenedor la interpreta como relativa al URI de solicitud 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 servlet.

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 solicitud actual.

Este comportamiento se encuentra en la característica Servlet 3.0 cuando se establece la propiedad com.ibm.ws.webcontainer.redirectwithpathinfo en 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 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 descriptores de módulo web (web.xml) y en 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 establecido.

La capacidad para definir páginas de error predeterminadas se suministra 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 figuran ejemplos de páginas de error y de páginas de error predeterminadas.

Reglas de prioridad de 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, ésta altera temporalmente (enmascara) cualquier página de error predeterminada que se especifique en un archivo web-fragment.xml. Tampoco 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 tiene 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 tiene prioridad sobre una página de error predeterminada especificada en el archivo ibm-web-ext.xml.

Reglas de esquema

Se aplican dos reglas al proceso de las páginas de error predeterminadas en los archivos web.xml o web-fragment.xml. Las reglas dependen de la versión de la característica del contenedor web, del esquema de Servlet utilizado y del valor de una propiedad personalizada Java.

Estas reglas surgen debido a que el perfil completo de IBM WebSphere Application Server V8.0, no admitía páginas de error predeterminadas en la el release de disponibilidad general V8.0. El soporte para páginas de error predeterminadas se añadió al perfil completo de Application Server en un paquete de servicio, mediante el APAR PM94199. El soporte para páginas de error predeterminadas se añadió al perfil Liberty de Application Server en un paquete de servicio, mediante el APAR PI05845. Dado que estas actualizaciones representan 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 la 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 sólo se procesan si la propiedad de sistema Java com.ibm.ws.webcontainer.allowdefaulterrorpage se establece en true. Si la propiedad de sistema Java no se establece o no se establece en true, la página de error predeterminada se ignora. 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 la característica de contenedor web 3.1.

    Si la versión de la característica del contenedor web es 3.1 o superior, una página de error predeterminada especificada en el archivo web.xml o en el archivo web-fragment.xml siempre se procesa, independientemente de qué versión de esquema de servlet se utilice, e independientemente de si la propiedad personalizada Java está establecido.

    Este caso se produce cuando un descriptor utiliza un esquema de Servlet 3.1, ya que el proceso de un descriptor que utiliza un esquema de Servlet 3.1 requiere la versión de la característica de contenedor web 3.1.

Atención: los fragmentos web no añadieron hasta Servlet 3.0. El archivo web-fragment.xml no tiene ningún esquema de Servlet 2.5.
Ejemplos de página de error y de página de error predeterminada
Página de error predeterminada que se define 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 el archivo 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 el archivo 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 el archivo 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">

Icono que indica el tipo de tema Tema de concepto

Términos y condiciones para centros de información | Comentarios


Icono de indicación de fecha y hora Última actualización: 15 de junio de 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_servlet31_behavior
Nombre de archivo:cwlp_servlet31_behavior.html