Consideraciones sobre Java Servlet

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

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_consid
File name: cweb_consid.html