WebSphere Application Server tradicionalVersión 9.0 da soporte a las especificaciones Servlet 3.1.
Obtenga información sobre las características y los cambios de comportamiento de Servlet 3.1.

New feature:
El producto da soporte a Servlet 3.1, que incluye características y cambios de comportamiento que se han introducido en la especificación Servlet 3.0. Consulte Funciones de la característica Servlet 3.1 para obtener más información. Si realiza la migración de Servlet 2.5 o anterior a Servlet 3.1, tenga en cuenta también los cambios de comportamiento de
Servlet 3.0.newfeat
Java™ Servlet 3.1 tiene muchas potentes funciones. Algunas de estas funciones no están completamente documentadas en la especificación Servlet 3.0 o bien implican
contrapartidas. Para aprovechar bien las nuevas funciones, revise los temas siguientes.
Anotaciones
Las anotaciones
Java Servlet 3.0 se recogen en módulos web de Servlet 2.5, que pueden
incluir exponer un servlet en la web. Tenga cuidado al actualizar los requisitos previos de una aplicación anterior,
ya que se procesan las nuevas anotaciones y el archivo JAR de requisitos previos podría incluir anotaciones
que no quiera aplicar.
Subida de archivos
Cuando se utiliza el soporte de subida de archivos (formularios
de varias partes) que es una novedad en Servlet 3.0, la ubicación predeterminada para grabar archivos es la
misma que el valor del atributo de contexto del servlet javax.servlet.context.tempdir. Por ejemplo, se
genera
C:\opt\WAS\profiles\node1\temp\node1\server1\fragmentTest\fragmentTest24.war
para una configuración con los atributos siguientes:
- profile home=C:\opt\WAS\profiles\node1
- server name=server1
- enterprise application name=fragmentTest
- web module name=fragmentTest24.war
Las vías de acceso relativas también son relativas a esta ubicación predeterminada.
Puede cambiar el valor del atributo de contexto de servlet
javax.servlet.context.tempdir de forma que sea relativo a otro directorio, estableciendo la
propiedad del sistema com.ibm.websphere.servlet.temp.dir. Esta propiedad del sistema afecta a todas las
aplicaciones en base al servidor completo. Por ejemplo, si establece
com.ibm.websphere.servlet.temp.dir en
/foo, el directorio temporal de la aplicación será
/foo/node1/server1/fragmentTest/fragmentTest24.war. Si desea cambiar el valor a nivel
de
aplicación, utilice el atributo scratchdir de JavaServer Pages (JSP). Para obtener más información sobre el atributo scratchdir, consulte el tema de parámetros de configuración del motor JSP.
Configuración de sesiones HTTP programáticas o dinámicas
La configuración de sesiones HTTP programáticas permite que una aplicación
modifique la configuración de la sesión que se está utilizando, ya sea
mediante la configuración del archivo
web.xml o mediante las llamadas al
método de la API. Después de iniciar la aplicación, no se puede cambiar un
nombre de cookie modificado dinámicamente. A efectos de
seguridad, los administradores pueden inhabilitar la configuración de sesiones programadas para determinadas
cookies que se pueden compartir entre aplicaciones. Generalmente, es seguro modificar la configuración
de las cookies, si la aplicación utiliza un nombre de cookie o vía de acceso exclusivos. Puede cambiar la vía
de acceso de cookie predeterminada para cada aplicación que utilice la raíz de contexto mediante la
gestión de sesiones.
Importante: Si cambia la vía de acceso
puede afectar determinadas extensiones de IBM®, por ejemplo, el
compartimiento de sesiones o el método IBMSessionExt.invalidateAll que se
basan en el uso de una cookie para varias aplicaciones.
Las cookies dinámicas tienen
el impacto siguiente en los servicios intermediarios:
- Un proxy de empresa recupera automáticamente una cookie dinámica
cuando se inicia una aplicación y utiliza la cookie para la afinidad de
sesiones.
- Un proxy DMZ en modalidad de seguridad baja o media también
recupera automáticamente una cookie dinámica cuando se inicia una
aplicación. Para un proxy DMZ en modalidad de seguridad alta, la
recuperación no es automática; la aplicación tiene que estar en ejecución
antes de que se exporte la información de direccionamiento de destino.
- Un plug-in de servidor web no puede obtener la cookie dinámica
automáticamente porque no se comunica con servidores de aplicaciones
para la información de configuración. Debe iniciar la aplicación, generar
la configuración del plug-in, propagar la configuración al plug-in y, a
continuación, volver a cargar la configuración para que el plug-in obtenga
la cookie.
- En el entorno de clúster, el nombre del cookie dinámico
generado en cada servidor debe ser el mismo, de lo contrario, es posible que los
servicios de intermediario frontales no puedan direccionar las solicitudes.