Fecha: 13 de Agosto de 2001 Relacionada con J2EE1.3 y Tomcat 4 Desde entonces ya ha aparecido la versión 2.4, emparejada con J2EE 1.

Transcripción

1 7. APÉNDICE 2. ESPECIFICACIÓN JAVA SERVLET 2.3 Fecha: 13 de Agosto de 2001 Relacionada con J2EE1.3 y Tomcat 4 Desde entonces ya ha aparecido la versión 2.4, emparejada con J2EE 1.4 y Tomcat INTRODUCCIÓN QUÉ ES UN SERVLET? Es un componente web Realizado en Java (al menos J2SE 1.2) Gestionado por un contenedor (motor de servlets)? Son extensiones de un servidor de web para dar soporte a los servlets Genera contenido dinámico Página 162

2 QUÉ ES UN CONTENEDOR DE SERVLETS? Es parte de un servidor de web o de un servidor de aplicaciones que ofrece los servicios de red sobre los que se efectúan las peticiones y respuestas decodifica las peticiones MIME formatea las respuestas MIME contiene y maneja los servlets a lo largo de su ciclo de vida Puede ser parte de un servidor de web o de un servidor de aplicaciones Puede ejecutarse En el mismo proceso que el servidor En otro proceso del mismo ordenador en el que se ejecuta el servidor En otro proceso de un ordenador diferente al que usa el servidor Debe soportar HTTP (recomendado 1.1), puede soportar otros protocolos tipo petición/respuesta, como HTTPS Puede establecer restricciones de seguridad sobre el entorno en el que se ejecutan los servlets Página 163

3 EJEMPLO 1) Un navegador realiza una petición HTTP al servidor de web 2) El servidor recibe la petición y la pasa al contenedor de servlets 3) El contenedor determina qué servlet activar dependiendo de su configuración, y lo llama pasándole objetos que representan la petición y la respuesta 4) El servlet, mediane el objeto petición, descubre de qué usuario se trata, qué parámetros se han enviado y otros datos relevantes. El servlet ejecuta las operaciones que le son propias, como cualquier programa, y devuelve los resultados al cliente mediante el objeto de respuesta 5) Cuando el servlet finaliza su trabajo, el contenedor verifica que la respuesta se ha enviado y devuelve el control al servidor de web Página 164

4 7.2. EL INTERFAZ SERVLET Es la abstracción principal del API de los servlets. Todos los servlets implementan este interfaz directamente o mediante la extensión de una clase (GenericServlet o HttpServlet) que implemente dicho interfaz MÉTODOS PARA MANEJO DE PETICIONES El interfaz Servlet define un método service para atender las solicitudes de los clientes. Este método se invoca para cada petición que el contenedor envía a una instancia de un servlet. La atención a peticiones concurrentes de la misma aplicación web suele necesitar que el desarrollador de servlets los diseñe de manera que puedan abordar el problema de tener múltiples threads ejecutando el método service simultáneamente. Habitualmente el contenedor aborda este caso ejecutando concurrentemente este método service en diferentes threads Página 165

5 1) Métodos específicos para manejo de peticiones HTTP La subclase HttpServlet añade métodos al interfaz Servlet que son llamados automáticamente por el método service para ayudar al procesamiente de peticiones HTTP? Estos métodos son doget, dopost, doput, dodelete, dohead, dooptions y dotrace Normalmente el programador sólo se preocupa de los métodos doget y dopost dohead es una versión de doget en la que se descarta el cuerpo del mensaje de respuesta 2) Soporte para GET condicional Esta operación permite solicitar un recurso sólo si éste ha sido modificado tras cierto momento. Para ello existe un método getlastmodified del interfaz HttpServlet Página 166

6 NÚMERO DE INSTANCIAS La declaración del servlet, que forma parte del descriptor de despliegue de la aplicación web correspondiente, controla la forma en la que el contenedor crea instancias del servlet. En caso de que no se trate de un entorno distribuido, el contenedor sólo debe usar una instancia por cada declaración de servlet. Para los servlets que implementen el interfaz SingleThreadModel, el contenedor puede crear múltiples instancias o bien serializarlas Nota sobre SingleThreadModel Se garantiza que sólo habrá un thread activo dentro del método service. Esta garantía sólo se aplica a cada instancia del servlet Los objetos accesibles a más de un servlet simultáneamente no heredan esta limitación aunque una instancia de un servlet con SingleThreadModel esté accediendo en un momento dado Página 167

7 CICLO DE VIDA DEL SERVLET Consiste en cuatro pasos que, en el API, vienen reflejados por los métodos init, service y destroy del interfaz javax.servlet.servlet que todos los métodos deben implementar directa o indirectamente a través de las clases abstractas GenericServlet o HttpServlet 1) Carga e instanciación Es responsabilidad del contenedor, que puede realizarla: al arrancar, o al llegar una petición para la que el contenedor determine que el servlet es necesario En el arranque, el contenedor debe localizar las clases para servlets y cargarlas mediante las operaciones normales de Java. Después se procede a su instanciación. Página 168

8 2) Inicialización Sirve para que los servlets puedan leer datos de configuración persistentes, inicializar recursos costosos y otras tareas. Para inicializar cada servlet, el contenedor llama al método init del interfaz Servlet con un objeto único que implementa el interfaz ServletConfig. Este objeto de configuración permite que el servlet acceda a los parámetros nombre-valor de inicialización procedentes de la información de configuración de la aplicación web. El objeto de configuración también facilita que el servlet acceda a un objeto (que implementa el interfaz ServletContext) que describe el entorno de ejecución del servlet Condiciones de error en la inicialización Posibilidades: UnavailableException y ServletException. El servlet no llega a entrar en funcionamiento y se descarta sin llamar a su método destroy El contenedor procede a crear otra instancia, salvo que deba esperar un tiempo si así se indica en el caso UnavailableException Consideraciones en cuanto a herramientas Los métodos de introspección pueden provocar llamadas a los métodos estáticos de inicialización, sin que esto suponga que un contenedor ha puesto en marcha al servlet Página 169

9 El programador sólo puede suponer que el servlet está en funcionamiento tras la invocación del método init 3) Manejo de peticiones Tras la inicialización, el contenedor emplea el servlet para atender peticiones de los clientes Estas peticiones vienen representadas por objetos del tipo ServletRequest El servlet rellena las respuestas mediante llamadas a un objeto del tipo ServletResponse Ambos objetos son parámetros del método service del interfaz Servlet Si se trata de una petición HTTP, los objetos son del tipo HttpServletRequest y HttpServletResponse Aspectos relativos a múltiples threads El programador debe preparar el código del método service considerando la posibilidad de concurrencia con múltiples threads en su ejecución Como alternativa el programador puede implementar el interfaz SingleThreadModel, que obliga a que el contenedor garantice que sólo hay un thread activo dentro de service. Opciones: Serializar las peticiones Disponer de una bolsa de instancias del mismo servlet (especialmente si el servlet es parte de una aplicación web distribuida) Página 170

10 .. CCUURRSSOO / / PPRROGRRAMACCIIÓN BBÁSSIICCA EEN EELL SSEERRVIIDORR. Para los servlets que no implementan SingleThreadModel, si se ha definido el método service con la palabra synchronized, el contenedor debe serializar las peticiones Esto limita el rendimiento, por lo que no es aconsejable Excepciones durante el manejo de peticiones ServletException: indica que ha ocurrido un error durante el procesamiento de la petición. El contenedor tomará las medidas oportunas UnavailableException: indica que el servlet ya no puede, temporal o definitivamente, atender peticiones? Si es permanente: el contenedor retirará al servlet del servicio, llamará a su método destroy y eliminará la instancia del servlet? Si es temporal: el contenedor puede optar entre no pasar peticiones al servlet mientras tanto (devolverá el código 500, SERVICE_UNAVAILABLE, y una cabecera Retry-After), o bien puede decidir tratarlo como el caso permanente Página 171

11 Seguridad en los threads La implementación de los objetos de petición y respuesta no tiene que garantizar su funcionamiento a prueba de threads, por lo que tan sólo deben usarse en el ámbito del servlet que atiende la petición Tampoco deben pasarse referencias de estos objetos a otros objetos que se ejecuten en otros threads, puesto que el comportamiento puede ser no determinista 4) Fin del servicio Cuando el contenedor determine que el servlet deba eliminarse del servicio, esperará un tiempo a que los threads que estén ejecutando el método service finalicen, y después llamará al método destroy del interface Servlet Así permite que el servlet libere los recursos que mantenga y guarde los datos necesarios La instancia del servlet quedará disponible para la recogida de residuos Página 172

12 7.3. CONTEXTO DEL SERVLET INTRODUCCIÓN AL INTERFAZ SERVLETCONTEXT Mediante el objeto ServletContext los servlets pueden: Anotar eventos Obtener URLs para acceder a recursos Establecer y consultar atributos a los que pueden acceder otros servlets del mismo contexto Cada objeto ServletContext se asocia a un URI del servidor de web. P.ej. Todas las peticiones que comiencen por /catalogo, denominado ruta del contexto, se dirigirán a la aplicación web asociada con el ServletContext ÁMBITO DE UN INTERFAZ SERVLETCONTEXT Para cada aplicación web existe un objeto que es instancia del interfaz ServletContext. Los servlets que no forman parte de ninguna aplicación web pertenecen a una aplicación por defecto con su correspondiente ServletContext Página 173

13 PARÁMETROS DE INICIALIZACIÓN Los métodos de ServletContext disponibles son: getinitparameter getinitparameternames ATRIBUTOS DE CONTEXTO Los servlets pueden dar de alta atributos que pasan a ser accesibles a todos los que forman parte de la misma aplicación web. Los métodos relacionados son: setattribute getattribute getattributenames removeattribute Atributos de contexto en un contenedor distribuido Los atributos son locales a la MV en que se crearon, por lo que no pueden emplearse en un entorno distribuido y deben reemplazarse por sesiones, bases de datos o EJBs como medio de comunicación entre servlets Página 174

14 RECURSOS El interfaz ServletContext permite acceder a la jerarquía de documentos estáticos que forman parte de la aplicación web mediante los siguientes métodos: getresource getresourceasstream Ambos métodos admiten como parámetro un String cuyo valor, comenzando con una barra (/) indica la ruta del recurso desde el origen del contexto. Estos métodos no se usan para obtener contenido dinámico (devolverían el código fuente sin procesar). Se puede averiguar la lista de recursos mediante el método getresourcepaths(string path) Página 175

15 7.4. LA PETICIÓN El objeto petición incluye toda la información procedente del cliente. En el protocolo HTTP esta información se transmite al servidor en las cabeceras y cuerpo del mensaje de la petición PARÁMETROS DEL PROTOCOLO HTTP Consiste en las cadenas enviadas por los clientes a un contenedor de servlets como parte de la petición. Cuando la petición se trata de un objeto HttpServletRequest y se dan las condiciones que a continuación se citan, entonces el contenedor rellena los parámetros a partir de la cadena de petición (query string) y de los datos del cuerpo. Los parámetros se almacenan en un conjunto de pares nombre-valor. Dado un nombre de parámetro se pueden obtener múltiples valores. Los métodos de que se dispone en el interfaz ServletRequest con este propósito son: getparameter getparameternames getparametervalues El método getparametervalues devuelve un vector de objetos de tipo String que contienen todos los valores asociados con un nombre de parámetro. El valor devuelto por getparameter debe ser el primero del vector de objetos devuelto por getparametervalues. Página 176

16 Los datos de la cadena de petición y del cuerpo del mensaje se unen para formar el conjunto de parámetros de la petición, colocándose la cadena de petición en primer lugar (para parámetros multievaluados). Para acceder a los parámetros relativos al path en operaciones GET deben parsearse los valores devueltos por los métodos getrequesturi y getpathinfo Momento en el que se puede acceder a los parámetros Condiciones necesarias para que el contenedor rellene los parámetros a partir de la información recibida: La petición es HTTP o HTTPS El método es POST El tipo de contenido es application/x-www-form-urlencoded El servlet ha realizado una llamada inicial a alguno de los métodos del tipo getparameter sobre el objeto petición Si no se dan las condiciones, el servlet puede acceder a los datos del cuerpo del mensaje mediante el stream de entrada del objeto; si, por el contrario, se dan las condiciones indicadas, este acceso desde el stream de entrada deja de ser posible. Página 177

17 ATRIBUTOS Son objetos asociados con una petición, y pueden ser modificados por el contenedor o por un servlet para ofrecer información a otros servlets (mediante RequestDispatcher). Los métodos para acceder a los atributos son: getattribute getattributenames setattribute Cada nombre de atributo puede tener un único valor asociado Los nombres de atributo que comiencen por el prefijo java., javax., sun. y com.sun. se encuentran reservados. El nombre de los atributos debe respetar la convención de nombre de dominio invertidos que se aplica en la denominación de paquetes. Página 178

18 CABECERAS Los siguientes métodos permiten que los servlets accedan a las cabeceras de una petición HTTP: getheader getheaders getheadernames El primero devuelve una cabecera a partir de su nombre. Puede haber varias que respondan a un mismo nombre, en cuyo caso getheader devolvería la primera, y getheaders devolvería un Enumeration de objetos String con todas. Las cabeceras pueden contener representaciones tipo String de valores int o Date, por lo cual aparecen los siguientes métodos del interfaz HttpServletRequest: getintheader getdateheader Si getintheader no puede convertir a int, activará NumberFormatException Si getdateheader no puede convertir a Date, activará IllegalArgumentException Página 179

19 ELEMENTOS DE LA RUTA DE LA PETICIÓN Se accede a ellos mediante el objeto de petición: ContextPath: prefijo asociado con el ServletContext al que pertenece este servlet. Si es el context por defecto asociado al origen del espacio de URLs del servidor, entonces su valor será la cadena vacía. En caso contrario, la ruta comienza por el símbolo / pero no finaliza con ese mismo símbolo. ServletPath: El fragmento de la ruta que se corresponde directamente con la concordancia que activó esta petición. Esta ruta comienza con una / salvo cuando la concordancia se obtuvo frente al patrón /*, en cuyo caso se trata de la cadena vacía. PathInfo: El fragmento sobrante de la ruta de la petición. Puede ser nada si no hay ruta extra, o bien una cadena que comienza con /. Para acceder a esta información se dispone de los siguientes métodos en el interfaz HttpServletRequest: getcontextpath getservletpath getpathinfo Salvo por diferencias de codificación de los URLs, siempre se satisface que requesturi = contextpath + servletpath + pathinfo Página 180

20 P.ej., supóngase la siguiente configuración: Context Path /catalog Asociación con servlets Patrón: /lawn/* Servlet: LawnServlet Asociación con servlets Patrón: /garden/* Servlet: GardenServlet Asociación con servlets Patrón: *.jsp Servlet: JSPServlet Entonces se produce el siguiente comportamiento: Ruta de la petición Elementos de la ruta /catalog/lawn/index.html ContextPath: /catalog ServletPath: /lawn PathInfo: /index.html /catalog/garden/implements ContextPath: /catalog ServletPath: /garden PathInfo: /implements /catalog/help/feedback.jsp ContextPath: /catalog ServletPath: /help/feedback.jsp PathInfo: nada Página 181

21 MÉTODOS DE TRADUCCIÓN DE LA RUTA Hay dos métodos para obtener la dirección dentro del sistema de ficheros equivalente a una ruta: ServletContext.getRealPath HttpServletRequest.getPathTranslated El primero toma como argumento un String y devuelve otro que representa un fichero del sistema local correspondiente. El segundo devuelve la ruta real correspondiente al pathinfo de la petición. Ambos métodos deben devolver nada si el contenedor no puede determinar la dirección dentro del sistema de ficheros COOKIES El método getcookies del interfaz HttpServletRequest devuelve un vector de cookies, que suelen contener al menos el nombre y su valor, ya que es lo mínimo que devuelve el navegador. Página 182

22 ATRIBUTOS SSL Si la petición ha sido transmitida sobre el protocolo seguro HTTPS, la información se hace accesible mediante el método issecure del interfaz ServletRequest. El contenedor debe hacer visibles los siguientes atributos al programador: Atributo Nombre del atributo Tipo Java Tipo de cifrado javax.servlet.request.cipher_suite String Tamaño en bits del algoritmo javax.servlet.request.key_size int Si hay un certificado SSL asociado con la petición, el contenedor debe hacerlo visible al programador como un vector de objetos del tipo java.security.cert.x509certificate y accesible mediante un atributo ServletRequest de java.servlet.request.x509certificate Página 183

23 INTERNACIONALIZACIÓN Opcionalmente los clientes pueden hacer llegar al servidor cuáles son sus preferencias lingüísticas. Tal información llega en la cabecera Accept-Language junto con otros mecanismos de HTTP/1.1. Métodos relativos del interfaz ServletRequest: getlocale getlocales El primero devuelve la preferencia del cliente según la sección 14.4 del RFC 2616 (HTTP/1.1). El segundo devuelve un Enumeration de objetos Locale que indican las preferencias lingüísticas del usuario en orden decreciente En caso de que no haya preferencia del cliente la llamada devolverá la del contenedor Página 184

24 CODIFICACIÓN DE DATOS DE LA PETICIÓN Muchos navegadores no envían un cualificador de la codificación con la cabecera Content- Type. Por defecto el contenedor supone ISO , y si los datos no se ajustan a esta codificación entonces el contenedor devolverá un valor vacío en el método getcharacterencoding Además hay un método setcharacterencondig (String enc) en el interfaz ServletRequest que permite a los programadores sobreescribir la codificación indicada por el contenedor Debe llamarse antes de comenzar a interpretar o leer los datos de la petición VIDA DE UN OBJETO PETICIÓN Cada objeto petición es válido únicamente dentro del ámbito del método service de un servlet, o bien en el método dofilter de un filtro Por rendimiento, los contenedores suelen reciclar los objetos petición, por lo que el uso de referencias a dichos objetos fuera de los ámbitos indicados puede llevar a comportamientos imprevisibles Página 185

25 7.5. LA RESPUESTA El objeto respuesta recoge toda la información que el servidor debe devolver al cliente En el protocolo HTTP esta información se encuentra en las cabeceras o en el cuerpo del mensaje de la petición BUFFERING Por rendimiento, el contenedor puede hacer buffering con la salida destinada a los clientes Suele ser una característica activada por omisión, pero los servlets pueden fijar parámetros Afectan tanto si el servlet emplea ServletOutputSream como Writer El contenedor debe enviar los datos inmediatamente al cliente en cuanto se llene el buffer Métodos del interfaz ServletResponse accesibles por los servlets con este propósito: getbuffersize setbuffersize iscomitted reset resetbuffer flushbuffer Página 186

26 getbuffersize devuelve un valor int con el tamaño del buffer asignado por el contenedor setbuffersize permite solicitar un buffer de tamaño mayor o igual al indicado Esto permite que el contenedor disponga de buffers preconstruidos de varios tamaños Debe llamarse antes de escribir, o provocará una IllegalStateException iscomitted devuelve un valor lógico indicando si se ha enviado ya algún byte al cliente flushbuffer fuerza a que se envíe al cliente la información contenida en el buffer reset elimina los datos del buffer, incluso cabeceras y códigos de estado, si todavía no se han enviado al cliente resetbuffer hace lo mismo sin modificar cabeceras ni códigos Tanto en reset como en resetbuffer se provoca una IllegalStateException si los datos ya se han enviado. El buffer no se modifica en tal caso Página 187

27 CABECERAS Los servlets puede fijar cabeceras en las respuesta HTTP mediante los siguientes métodos del interfaz ServletResponse: setheader addheader El primero crea una cabecera con un nombre y valor, sustituyendo a la que pudiera existir antes con el mismo nombre, sea cual sea su valor o valores addheader añade un valor a los preexistentes para una cabecera que, si no existía aún, se crea La información de las cabeceras es de tipo int o Date, por lo que el interfaz HttpServletResponse dispone de una serie de métodos para facilitar el trabajo del servlet: setintheader, setdateheader, addintheader y adddateheader El servlet debe asegurarse de fijar adecuadamente el valor de la cabecera Content-Type, pero como esta cabecera no es siempre necesaria según el estándar HTTP 1.1, el contenedor no establece ningún valor por defecto para esta cabecera cuando el servlet no lo ha hecho Página 188

28 MÉTODOS DE CONVENIENCIA El interfaz HttpServletResponse establece estos métodos de utilidad: sendredirect senderror El primero coloca las cabeceras y contenidos adecuados para redirigir al cliente a otra dirección. Si se devuelve un URL relativo que el contenedor no pueda transformar en dirección absoluta, entonces se produce una IllegalArgumentException senderror establece las cabeceras y contenidos adecuados para devolver al cliente un mensaje de error. Opcionalmente se puede suministrar un argumento String que el método senderror empleará como contenido del mensaje de error. Estos dos métodos tienen como efecto adicional que se complete y finalice la respuesta. Tras el uso de estos métodos el servlet ya no puede comunicar información al cliente. Si habían datos en el buffer de respuesta que no se han trasladado al cliente, serán reemplazados con los que colocan estos métodos. Si la respuesta ya se ha completado cuando se usan estos métodos, entonces se provoca una IllegalStateException Página 189

29 INTERNACIONALIZACIÓN El interfaz ServletResponse posee un método setlocale para que el servlet pueda establecer los atributos del idioma en la respuesta, modificando la cabecera Content-Language del mensaje Debería invocarse antes del método getwriter para que el objeto PrintWriter devuelto se encuentre configurado adecuadamente Obsérvese que el método setcontenttype tiene preferencia sobre setlocale La codificación por omisión es la ISO CIERRE DEL OBJETO RESPUESTA Inmediatamente tras el cierre de la respuesta el contenedor debe transferir al cliente todo el contenido restante del buffer de respuesta. Los siguientes eventos desencadenan este cierre: 1) Fin del método service del servlet 2) Se ha escrito en la respuesta una cantidad de información igual a la especificada mediante setcontentlength 3) Se ha activado el método senderror 4) Se ha activado el método sendredirect Página 190

30 VIDA DE UN OBJETO RESPUESTA Cada objeto respuesta es válido únicamente dentro del ámbito del método service de un servlet, o bien en el método dofilter de un filtro Por rendimiento, los contenedores suelen reciclar los objetos respuesta, por lo que el uso de referencias a dichos objetos fuera de los ámbitos indicados puede llevar a comportamientos imprevisibles Página 191

31 7.6. INTRODUCCIÓN A LOS FILTROS Un filtro es una fragmento reutilizable de código que puede transformar el contenido de las peticiones, respuestas y cabeceras de los mensajes HTTP. Se comportan como adaptadores de peticiones para un recurso o de respuestas desde un recurso Los filtros pueden trabajar sobre contenido estático o dinámico Las funciones disponibles para el programador en cuanto a filtros incluyen: Acceso a un recurso antes de la llegada de peticiones Procesamiento de una petición referente a un recurso antes de que se invoque Modificación de las cabeceras de petición y de los datos transformando la petición en otra personalizada Modificación de las cabeceras de respuesta y de los datos transformando la respuesta en otra personalizada Intercepción de la invocación de un recurso tras su llamada Acciones sobre un servlet, sobre un grupo de servlets o sobre contenido estático por una lista ordenada de filtros Página 192

32 Ejemplos de componentes de filtro De autentificación De anotaciones cronológicas y auditoría De conversión de imágenes De compresión de datos De cifrado De procesamiento de la cadena de petición De disparo ante eventos de acceso a recursos De transformación mediante XSLT de contenido XML De cadenas de tipos MIME De caching Página 193

33 7.7. SESIONES HTTP es, por su diseño, un protocolo sin estado; sin embargo en el desarrollo de aplicaciones para web es imprescindible relacionar las peticiones que realiza un mismo cliente. La especificación define un único interfaz HttpSession que permite que un contenedor utilice alguna de las alternativas de seguimiento de las sesiones de usuario, sin que los detalles de cada aproximación afecten al programador. Cookies MECANISMOS DE SEGUIMIENTO DE SESIONES Todos los contenedores han de soportar este sistema porque es el mecanismo más usado para el seguimiento de sesiones. El contenedor envía un cookie al cliente. A partir de ese instante el cliente devolverá dicho cookie en cada petición al servidor, asociando sin ambigüedad la petición a una sesión. Sesiones SSL El nombre de los cookies de este tipo debe ser JSESSIONID SSL, y por tanto HTTPS, incorpora un mecanismo para distinguir los accesos que forman parte de una sesión; por ello es fácil que el contenedor de servlets saque provecho de esta característica Página 194

34 Reescritura de URLs Constituye el mínimo denominador común para el seguimiento de sesiones, y se emplea cuando ninguno de las otras alternativas funciona. La reescritura de direcciones incluye la adición del identificador de sesión al URL interpretado por el contenedor para asociar la petición a una sesión. El identificador de sesión debe codificarse como un parámetro en la cadena del URL, y su nombre debe ser jsessionid, como en: Página 195

35 CREACIÓN DE UNA SESIÓN Se considera que la sesión es nueva si el contenedor no tiene forma de asociar la petcición actual con otras peticiones previas. Se satisface algunas de las siguientes condiciones: El cliente no tiene constancia de que existe una sesión El cliente escoge no unirse a una sesión ÁMBITO DE LA SESIÓN Los objetos HttpSession deben circunscribirse al nivel del contexto del servlet, de manera que los objetos referenciados y sus atributos nunca deben compartirse entre contextos Página 196

36 ASOCIACIÓN DE ATRIBUTOS EN UNA SESIÓN Un servlet puede ligar un atributo, mediante su nombre, a una sesión. Cualquier objeto asociado a una sesión es accesible por cualquier otro servlet perteneciente al mismo ServletContext y que atienda una petición identificada como parte de la misma sesión. Algunos objetos necesitan que se les notifique cuando sean asociados o eliminados de una sesión; para ello el objeto debe implementar el interfaz HttpSessionBindingListener con los métodos: valuebound valueunbound El primero debe llamarse antes de poder acceder al objeto mediante el método getattribute del interfaz HttpSession. El segundo debe invocarse en cuanto el objeto deje de estar accesible mediante el mismo método getattribute Página 197

37 VENCIMIENTO DE SESIONES El protocolo HTTP no contempla cómo puede conocerse que un cliente ha dejado de estar activo, por lo que sólo puede emplearse un timeout con este propósito. El método getmaxinactiveinterval de HttpSession indica el tiempo, en segundos, de vencimiento de sesiones para el contenedor. Este tiempo puede ser modificado mediante setmaxinactiveinterval. Un valor de -1 indica que la sesión nunca vence TIEMPOS DE ÚLTIMO ACCESO El método getlastaccessedtime permite averiguar cuándo, antes de la petición actual, se accedió por última vez a esta sesión. Página 198

38 SEMÁNTICAS IMPORTANTES EN LAS SESIONES 1) Aspectos relativos a los threads Varios servlets pueden acceder al mismo tiempo a un objeto de sesión, por lo que el desarrollador tiene la responsabilidad de sincronizar tales accesos cuando sea necesario. 2) Entornos distribuidos En las aplicaciones distribuidas todas las peticiones que forman parte de una sesión deben ser atendidas por una misma máquina virtual. El contenedor debe proveer los métodos setattribute y putvalue, por lo que se imponen las siguiente limitaciones: El contenedor debe aceptar objetos que implementan el interfaz Serializable El contenedor puede seleccionar ofrecer almacenamiento de otros objetos indicados en la HttpSession, como referencias a componentes Enterprise JavaBean y transacciones La migración de sesiones será realizada mediante servicios específicos del contenedor El contenedor puede provocar una IllegalArgumentException cuando se coloque en una sesión un objeto que no sea Serializable o para el que no se haya diseñado un soporte específico para la migración de la sesión que lo contenga. De esta manera se eliminan los problemas de concurrencia adicionales a los presentes en un contenedor no distribuido. Página 199

39 3) Semánticas en el cliente El programador siempre debe asumir que todas las ventanas del navegador participan en la misma sesión. Esto viene motivado por el hecho de que el navegador controla tanto los cookies como los certificados SSL, y no están asociados a una ventana concreta del navegador Página 200

40 7.8. ATENCIÓN DE PETICIONES En muchas ocasiones es útil derivar la atención de una petición a otro servlet, o incluir los resultados de otro servlet en la respuesta. El interfaz RequestDispatcher ofrece un mecanismo para conseguirlo OBTENCIÓN DE UN REQUESTDISPATCHER Se puede obtener un objeto que implemente el interfaz RequestDispatcher del ServletContext mediante los métodos getrequestdispatcher getnameddispatcher El primero toma un String como argumento que describe la ruta dentro del ámbito del ServletContext, busca un servlet con esa ruta y lo recubre con un objeto RequestDispatcher devolviendo el objeto resultante Esta ruta debe ser relativa al origen del ServletContext y comenzar con una / Si no hay ningún servlet con esa ruta, el resultado será un RequestDispatcher que devolverá el contenido de la ruta Página 201

41 getnameddispatcher toma un String como argumento que indique el nombre de un servlet conocido por el ServletContext. Si se encuentra un servlet, será recubierto con un objeto RequestDispatcher y devuelto como resultado. Si no hay ningún servlet asociado, el método devuelve null Para poder usar rutas relativas a la de la petición actual en lugar de relativa al origen de ServletContext, en el interfaz ServletRequest se encuentra el método getrequestdispatcher, cuyo comportamiento es similar al de ServletContext. P.ej. si el origen del contexto es / y llega una petición /garden/tools.html, el dispatcher obtenido por ServletRequest.getRequestDispatcher( header.html ) será idéntico al de ServletContext.getRequestDispatcher( /garden/header.html ) Los métodos que crean objetos RequestDispatcher permiten la aparición de parámetros en las cadenas de petición. Estos parámetros tiene precedencia sobre los que, con el mismo nombre, pudieran pasarse al servlet por otra vía USO DE UN DISPATCHER DE PETICIONES El servlet debe llamar al método include o forward del interfaz RequestDispatcher. Los parámetros pueden ser argumentos de la petición o de la respuesta, o instancias de las subclases que recubren a las clases de petición y respuesta. Página 202

42 EL MÉTODO INCLUDE El servlet objetivo del método include tiene acceso a todos los elementos del objeto petición, pero su uso del objeto respuesta se encuentra más limitado; sólo puede: Escribir información al ServletOutputStream o al Writer del objeto respuesta Finalizar la respuesta escribiendo contenido hasta completar el buffer de respuesta, o llamando explícitamente al método flushbuffer del interfaz ServletResponse. No puede modificar las cabeceras o llamar a ningún otro método que las modifique Un servlet activado en un include accede al path mediante los siguientes atributos obtenidos con getattribute: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info y javax.servlet.include.query_string salvo que el servlet fuera activado con getnameddispatcher Página 203

43 EL MÉTODO FORWARD Sólo puede ser invocado cuando el cliente todavía no ha comenzado a recibir resultados procedentes del servlet, en cuyo caso se produciría una IllegalStateException. El path del objeto petición transmitido al servlet destino debe reflejar el usado para obtener el RequestDispatcher. Excepción: cuando se ha utilizado getnameddispatcher para obtener el RequestDispatcher, en cuyo caso el path debe coincidir con el de la petición original. Antes de que finalice el método forward se debe enviar el contenido de respuesta. El mecanismo de reparto de peticiones debe responsabilizarse de añadir parámetros a la cadena de petición cuando realiza operaciones forward o include MANEJO DE ERRORES Si el servlet destino de un request dispatcher produce una excepción en ejecución o una excepción comprobada del tipo ServletException o IOException, ésta debería propagarse hasta el servlet que lo llamó. Todas las demás excepciones deberían transformarse en ServletException y establecer como causa la de la excepción original antes de propagarse. Página 204

44 7.9. CORRESPONDENCIA ENTRE PETICIONES Y SERVLETS USO DE RUTAS URL Tras recibir la petición de un cliente, el contenedor determina la aplicación web a la que debe pasársela. La aplicación seleccionada debe tener la más larga ruta que coincida con el comienzo del URL de petición. La parte concordante del URL es el path de contexto cuando de asocian a servlets. A continuación el contenedor debe encontrar al servlet que debe procesar la petcición mediante el procedimiento de correspondencia de rutas que se describe a continuación: La ruta empleada para asociar a un servlet es el URL de la petición menos el context path. Las siguientes reglas se emplean ordenadamente de forma que la primera que se satisfaga se aplicará: 1) El contenedor intentará encontrar una coincidencia exacta entre la ruta de la petción y la ruta del servlet. Si se encuentra, se selecciona el servlet. 2) El contenedor intentará encontrar la coincidencia más larga de forma recursiva. Esto se consigue descendiendo paso a paso por el directorio de la ruta del path, usando como separador el símbolo /. La coincidencia más larga determina el servlet seleccionado. Página 205

45 3) Si el último segmento del path contiene una extensión (p.e. jsp), el contenedor intentará encontrar un servlet que maneje peticiones para dicha extensión. 4) Si ninguna de las reglas anteriores se satisface, el contenedor intentará servir contenido adecuado para el recursos solicitado. En caso de que exista un servlet por defecto para la aplicación, se usará. Para las comparaciones de cadenas el contenedor considera diferentes mayúsculas y minúsculas. Página 206

46 ESPECIFICACIÓN DE LAS CORRESPONDENCIAS En el descriptor de despliegue de la aplicación web se emplea la siguiente sintaxis para definir correspondencias: Para correspondencia de rutas se usa una cadena que comienza por el carácter / y finaliza con /* Para correspondencia de extensiones se emplea una cadena que comienza con el prefijo *. Si la cadena sólo contiene el carácter / entonces referencia al servlet por defecto de la aplicación.? En tal caso la ruta del servlet es el URI menos la ruta del contexto, y el path info es null. Todas las demás cadenas sólo se usan para coincidencisa exactas 1) Correspondencias implícitas Si el contenedor posee un contenedor JSP, la extensión *.jsp le estará implícitamente asignada salvo que la aplicación web defina una correspondencia explícita, que tendría precedencia. En general el contenedor puede realizar correspondencias implícitas siempre y cuando las explícitas tengan preferencia. Página 207

47 2) Ejemplo de juego de correspondencias P.ej., supóngase las siguientes correspondencias: Patrón de la ruta servlet /foo/bar/* servlet1 /baz/* servlet2 /catalog servlet3 *.bop servlet4 Entonces se produce el siguiente comportamiento: Ruta de la petición /foo/bar/index.html /foo/bar/index.bop /baz /baz/index.html /catalog /catalog/index.html /catalog/racecar.bop /index.bop servlet que ha de atender la petición servlet1 servlet1 servlet2 servlet2 servlet3 servlet por defecto servlet4 servlet4 Obsérvese que el servlet asociado a /catalog no se emplea en las peticiones 6 y 7 porque la correspondencia no es exacta Página 208