1 2 Java Servlets

Curso: "Java EE y Frameworks" 2013
Sevlets
Mdulo 1 / parte 2

Todos los logos y marcas utilizados en este
documento, estn registrados y pertenecen a
sus respectivos dueos.
Todos los logos y marcas utilizados en este
documento, estn registrados y pertenecen a
sus respectivos dueos.
AUTORES: andresguzf@gmail.com WEB: http://formacion-java.bolsadeideas.cl | Servlets 1


Introduccin.
Servlets.
Los servlets son objetos que corren dentro del contexto de un contenedor de servlets (ej:
Tomcat) y extienden su funcionalidad. Tambin podran correr dentro de un servidor de
aplicaciones (ej: OC4J Oracle) que adems de contenedor para servlet tendr contenedor para
objetos ms avanzados como son los EJ B (Tomcat slo es un contenedor de servlets).
La palabra servlet deriva de otra anterior, applet, que se refera a pequeos programas escritos
en J ava que se ejecutan en el contexto de un navegador web. Por contraposicin, un servlet
es un programa que se ejecuta en un servidor.
El uso ms comn de los servlets es generar pginas web de forma dinmica a partir de los
parmetros de la peticin que enve el navegador web.
Servidores con contenedores Web.
Todo servidor de aplicaciones J EE contiene un contenedor Web, sin embargo existen algunos
servidores que slo contienen implementada esta parte de la plataforma.
J etty es un ejemplo de ello, sin embargo el ms usado es Tomcat (tambin llamado J akarta
Tomcat o Apache Tomcat), el cual funciona como un contenedor de servlets desarrollado bajo
el proyecto J akarta en la Apache Software Foundation. Tomcat implementa las
especificaciones de los servlets y de J avaServer Pages (J SP) de Sun Microsystems.



Java Servlets.
Definicin
Un servlet es un objeto que se ejecuta en un servidor o contenedor J EE, fue especialmente
diseado para ofrecer contenido dinmico desde un servidor web, generalmente es HTML.
Otras opciones que permiten generar contenido dinmico son con los lenguajes ASP, PHP,
J SP (un caso especial de servlet) y Python.
Un servlet es un objeto J ava que implementa la interfaz javax.servlet.Servlet o hereda alguna
de las clases ms convenientes para un protocolo especfico (ej.: javax.servlet.HttpServlet).
Al implementar esta interfaz el servlet es capaz de interpretar los objetos de tipo
HttpServletRequest y HttpServletResponse quienes contienen la informacin de la pgina que
invoc al servlet.
Entre el servidor de aplicaciones (o web content) y el servlet existe un contrato que determina
cmo han de interactuar. La especificacin de ste se encuentra en los J SR (J ava Specification
Requests) del J CP (J ava Community Process).
Aplicaciones Web.
La especificacin J ava Servlet 2.2 present al menos dos caractersticas importantes: una
aplicacin Web y un archivo de aplicacin Web (WAR), de acuerdo a las especificaciones
Servlets 2.2:

Nota: Una aplicacin Web es una coleccin de servlets, pginas HTML, clases, y otros recursos que se
pueden empaquetar y ejecutar en varios contenedores de distintos vendedores.

Los WARs simplemente son archivos J ava de una aplicacin Web con una extensin diferente
para diferenciarlos de los comnmente usados J ARs.


Antes de la especificacin Servlet 2.2, era bastante diferente desplegar Servlets entre
diferentes contenedores servlets -- anteriormente tambin llamados motores servlet. La
especificacin 2.2 estandariz el despliegue entre contenedores, llevando as la portabilidad
del cdigo J ava un paso ms all. Veremos el poder de esto ms adelante, cuando ilustremos
la creacin de una sencilla aplicacin Web que se despliegue en Apache Tomcat.
Estructura de Directorios de la Aplicacin Web
La especificacin Servlet 2.2 define la estructura de directorios para los ficheros de una
aplicacin Web. El directorio superior -- o directorio raz -- debera tener el nombre de la
aplicacin y definir la raz de documentos para nuestra aplicacin Web. Todos los ficheros
debajo de esta raz pueden servirse al cliente excepto aquellos ficheros que estn bajo los
directorios especiales META-INF y WEB-INF en el directorio raz. Todos los ficheros privados --
como los ficheros class de los servlets -- deberan almacenarse bajo el directorio WEB-INF.
En la siguiente figura podemos ver la estructura de directorios de una aplicacin Web:

Para crear una aplicacin Web, empezamos creando esta estructura de directorio. Toma tu
fichero de la clase del servlet compilado y sitala en el directorio WEB-INF/classes. Si hemos
definido que nuestro servlet pertenece a un paquete, debemos seguir las reglas estndar de
J ava y crear los subdirectorios apropiados para que la J VM puedan encontrar nuestras clases.



Por ejemplo, si nuestro servlet est definido en un paquete com.mycompany.myproject,
deberamos crear la siguiente estructura de directorios:
/WEB-INF
|-- classes
| |-- com
| |-- mycompany
| |-- myproject

Sita tus clases J ava en el subdirectorio myproject.
Una alternativa til para copiar los ficheros de clases al directorio apropiado es configurar
nuestro entorno de construccin (un Makefile o IDE) para salvar las clases compiladas
directamente en los directorios requeridos. Hacer esto nos ahorrar este paso durante el
desarrollo.



Peticiones HTTP GET y POST
La gran mayora de las peticiones de los usuarios en un navegador web son del tipo HTTP GET
y HTTP POST.

Peticin GET: El usuario ingresa la informacin que es anexada hacia una URL en un
query string. Solo se puede enviar un limitado limitada cantidad de dato:
/servlet/VerCurso?FirstName=Andres&LastName=Guzman

Peticin POST: El usuario ingresa la informacin que es enviada como datos en la
peticin HTTP post (no es anexada a la URL). Puede enviar un ilimitada cantidad de
informacin, principalmente es usado para procesar los formularios.



Clases Servlet y HttpServlet.
A continuacin se sealarn las propiedades ms especficas de los servlets junto con las
clases ms importantes de cada paquete y una pequea explicacin de su utilizacin y su
aporte para el manejo de servlets.
Para entender mejor la relacin entre las clases realizamos este pequeo esquema en el cual
en rojo se encuentran las herencias directas de clases o interfaces y en negro se encuentran
las relaciones de uso entre clases.

Un servlet ampla las funcionalidades de un servidor ofreciendo un servicio especfico dentro de
un marco de trabajo bien definido. Es una pequea pieza de cdigo J ava - normalmente una
sola clase -- que proporciona un servicio especfico. Por ejemplo, un servlet HTTP podra
proporciona a un cliente de un banco los detalles de sus depsitos y reintegros recientes. Otro
servlet HTTP podra permitir a un cliente, ver, e incluso editar su direccin de correo.


Para desplegar un servlet, normalmente se requiere la configuracin de un servidor de
aplicaciones. Cuando el servidor encuentra un tipo particular de solicitud, invoca al servlet,
pasndole los detalles sobre la solicitud y un objeto response para devolver el resultado.
Ejemplo de Servlet



Interfaz Servlet
Todos lo servlets implementan el interface javax.servlet.Servlet bien directamente -- en el caso
de los servelts genricos -- o indirectamente, en el caso de los servlets HTTP o J SP. El
interface javax.servlet.Servlet incluye los siguientes mtodos importantes:
init(): Define cualquier cdigo de inicializacin que debera ejecutarse cuando se carga
el servlet en memoria.
service(): El mtodo principal, llamado cuando el servlet recibe una solicitud de
servicio. Define un paquete de lgica de procesamiento proporcionado por el servlet.
destroy(): Define cualquier cdigo de limpieza requerido antes de eliminar el servlet de
la memoria.
Cuando el contenedor servlet carga por primera vez un servlet invoca al mtodo init() del
servlet para inicializarlo. Luego segn se hacen solicitudes para ejecutar el servlet, el
contenedor servlet llama repetidamente la mtodo service() del servlet. Finalmente, cuando el
contenedor servlet no necesita el servlet, llama al mtodo destroy() del servlet y lo descarga de
la memoria. Observa que durante el tiempo de vida de un simple ejemplar servlet, los mtodos
init() y destroy() slo son invocados una vez, mientras que el mtodo service() ser invocado
muchas veces -- una cada vez que se haga una solicitud para ejecutar el servlet.



Ejemplo de mtodo init(): Leyendo parmetros de
configuracin del web.xml



Configurando los parmetros en: el archivo
de despliegue web.xml



Ejemplo mtodo Destroy:



Clase HttpServlet
Los servlets HTTP extienden la clase javax.servlet.http.HttpServlet. Esta clase extiende la clase
javax.servlet.GenericServlet, que a su vez implementa javax.servlet.Servlet. La clase
HttpServlet sobreescribe el mtodo service() de forma que puede manejar diferentes tipos de
solicitudes HTTP: DELETE, GET, OPTIONS, POST, PUT, y TRACE. Por cada uno de estos
tipos de solicitud, la clase HttpServlet proporciona su correspondiente mtodo doXXX().
Aunque podemos sobrescribir el mtodo service() en nuestra clase servlet, raramente hay
alguna necesidad de hacerlo. Ms frecuentemente querremos sobrescribir mtodos doXXX()
individuales.
Si sobrescribimos el mtodo service(), debemos tener cuidado de que los mtodos doXXX() por
defecto, slo sean llamados si llamamos a super.service o los invocamos directamente.
Para la mayora de las aplicaciones querremos sobrescribir los mtodos doPost() y doGet(), ya
que ellos manejan normalmente los datos enviados por un formulario de usuario desde un
FORM HTML.


Para sumarizar, cuando escribamos nuestros servlets HTTP, deberamos:
Importar como mnimo las clases servlets:
o javax.servlet.ServletException
o javax.servlet.http.HttpServlet
o javax.servlet.http.HttpServletRequest
o javax.servlet.http.HttpServletResponse
Hacer la clase public
Hacer que la clase extienda HttpServlet
Sobrescribir los mtodos doXXX() apropiados para implementar nuestra lgica de
solicitud/respuesta.
En el ejemplo de abajo hemos ilustrado un simple servlet HTTP. La primera lnea simplemente
define a qu paquete pertenece el servlet. El siguiente bloque de cdigo importa las clases
usadas en este servlet. Luego viene la definicin de la clase servlet. Como puedes ver, la clase
RequestDetails extiende HttpServlet.


El cuerpo de RequestDetails define dos mtodos: doGet() y doPost(). El mtodo doGet() define
la funcionalidad principal de este servlet. El mtodo doPost() simplemente llama a doGet(). Por
lo tanto, el servlet maneja las peticiones GET y POST de la misma forma.
El mtodo doGet() construye una pgina HTML que contiene detalles sobre la solicitud HTTP
enviada al servidor. Observa las dos primeras lneas del mtodo. La primera lnea selecciona el
tipo de contenido de la respuesta. En general, construiremos una pgina HTML, en cuyo caso
el tipo de contenido debe configurarse como text/html. La segunda lnea del mtodo doGet()
obtiene una referencia a un stream de salida PrintWriter.



Toda la salida a devolver para el cliente se escribe en este stream de salida:
package org.stevengould.javaworld;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;
import java.util.Enumeration;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* This class provides a simple example of a servlet, and
* illustrates some of the information available from an
* HTTP request.
*/
public class RequestDetails extends HttpServlet {
/**
* Handler for all GET requests. We simply dump out the
* requestheader information, followed by the body of
* the request.
* @param request the HTTP request submitted to the
* server for processing. It is this object that
* contains the details of the requested URL, and
* it is the details of this object that we
* output as a response.
* @param response the response object to be used to
* send a result back to the client.
* @exception IOException thrown if a communications
* error occurs.
*@exception ServletException if the GET request could
* could not be handled
*/
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head>");
out.println("<title>Request Details Example</title>");
out.println("</head>");


out.println("<body>");
out.println("<h3>HTTP Request Header</h3>");
out.println("<table border='1'>");
out.println(" <tr bgcolor=#e0e0e0>");
out.println(" <td><strong>Name</strong></td>");
out.println(" <td><strong>Value</strong></td>");
out.println(" </tr>");
Enumeration e = request.getHeaderNames();
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
String value = request.getHeader(name);
out.println(" <tr>");
out.println(" <td bgcolor=#e0e0e0>"+name+"</td>");
out.println(" <td>"+value+"</td>");
}
out.println("</table>");
out.println("<h3>HTTP Request Information</h3>");
out.println("<table border='1'>");
out.println(" <tr bgcolor=#e0e0e0>");
out.println(" <td><strong>Name</strong></td>");
out.println(" <td><strong>Value</strong></td>");
out.println(" <td bgcolor=#e0e0e0>Method:</td>");
out.println(" <td>"+request.getMethod()+"</td>");
out.println(" <td bgcolor=#e0e0e0>Request URI:</td>");
out.println(" <td>"+request.getRequestURI()+"</td>");
out.println(" <td bgcolor=#e0e0e0>Protocol:</td>");
out.println(" <td>"+request.getProtocol()+"</td>");
out.println(" <td bgcolor=#e0e0e0>PathInfo:</td>");
out.println(" <td>"+request.getPathInfo()+"</td>");
out.println(" <td bgcolor=#e0e0e0>Remote Address:</td>");


out.println(" <td>"+request.getRemoteAddr()+"</td>");
out.println("</table>");
out.println("<hr>");
Date date = new Date();
out.println("<p align=center>Page generated on "+date);
out.println("</body>");
out.println("</html>");
out.close();
}
/**
* For POST requests, we will simply perform the same
*operations as for GET requests. The best way to do this
* is to simply invoke the doGet() method with the appropriate
* parameters.
* @param request the HTTP request submitted to the server
* for processing. It is this object that contains
* the details of the requested URL, and it is the
* details of this object that we output as a
* response.
* @param response the response object to be used to send a
* result back to the client.
*/
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws IOException, ServletException {
doGet(request, response);
}
}



En el siguiente ejemplo tenemos un servlet que nos saluda y cuenta las invocaciones a
doGet():
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;

public class SaludoContador extends HttpServlet {

/* Contador de veces que se invoca doGet() */
int contador = 0;

public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {

response.setContentType("text/html");

PrintWriter out = response.getWriter();
contador++;

out.println("<html>");
out.println("<head><title>Bienvenido al servlet contador" +
"</title></head>");
out.println("<body bgcolor=\"#FFFF9D\"><FONT " +
"color=\"#000080\" FACE=\"Arial,Helvetica,Times\" SIZE=2>" +
"<CENTER>&ltH3>Servlets</H3></CENTER>");

Date d = new Date();
out.println("<HR><p>Hola Mundo!. Fecha y hora: " +
d.toString() + "</p>");
out.println("<p>Nmero de invocaciones a doGet(): " +
contador + "</p>");

out.println("</body></font></html>");
}
}



Archivo de despliegue.
Ahora deberamos tener todos nuestros ficheros en su lugar para crear nuestra primera
aplicacin Web. En este punto, necesitamos realizar otra tarea: actualizar el descriptor de
despliegue para registrar nuestros servlets con el contenedor. Para crear fcilmente un
descriptor de despliegue, simplemente editamos uno existente. Abajo tenemos un esqueleto de
un fichero web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID"
version="2.5">


</web-app>

Insertamos nuestros descriptores de despliegue de servlets entre las etiquetas <web- app>y
</web-app>de este fichero. El descriptor de despliegue de un servlet debe incluir las siguientes
etiquetas (en este orden):
<servlet>
<servlet-name>nombre</servlet-name>
<servlet-class>package.nombre.MiClass</servlet-class>
</servlet>

Tambin estn permitidas antes de la etiqueta de cierre </servlet>varias etiquetas opcionales,
que definen las propiedades de ejecucin del servlet. Estas etiquetas definen propiedades
como parmetros de inicializacin, si el servlet debera o no cargarse en la arranada, los roles


de seguidad, y las propiedades de pantalla (incluyendo iconos grandes y pequeos, nombre de
pantalla y una descripcin).
Hasta ahora, nuestro descriptor de despliegue ha descrito el servlet al contenedor de servlets.
Luego, debemos describir cundo el contenedor de servlets debe invocar al servlet -- nos
referimos a esto como mapeo. En otras palabras, debemos describir cmo se mapea una URL
al servlet. En el fichero web.xml, las URLs se mapean de esta forma:
<ser vl et - mappi ng>
<ser vl et - name>nombr e</ ser vl et - name>
<ur l - pat t er n>pat t er n</ ur l - pat t er n>
</ ser vl et - mappi ng>

OK, suficiente teora. Veamos un ejemplo de un descritor de despliegue de una aplicacin Real.
Abajo podemos ver el fichero web.xml mnimo que describe nuestro servlet de ejemplo
RequestDetails:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID"
version="2.5">
<servlet>
<servlet-name>RequestDetails</servlet-name>
<servlet-class>
org.stevengould.javaworld.RequestDetails
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>RequestDetails</servlet-name>
<url-pattern>SampleServlet</url-pattern>
</servlet-mapping>
</web-app>



Como puedes ver en la etiqueta de mapeo, hemos elegido la URL /SampleServlet para mapear
nuestro servlet RequestDetails.
Ya est! Hemos creado nuestra primera aplicacin Web que contiene un slo servlet. Ahora
deberamos poder desplegar esta aplicacin en cualquier contenedor servlet compatible con la
especificacin 2.5.
De esta forma sabremos cmo trabajar con ellas y como desplegar nuestras aplicaciones Web
en un modo de desarrollo. Sin embargo, en un entorno de produccin, mantener juntos los
ficheros relacionados es ms conveniente.

Desplegar Aplicaciones Web en Tomcat.
Para desplegar nuestra aplicacin Web en Tomcat, copiamos el directorio raz de nuestra
aplicacin -- el que contiene web.xml y sus subdirectorios -- al subdirectorio
webapps/ROOT/ de nuestra instalacin de Tomcat. Podramos querer salvar una copia de la
aplicacin Web por defecto antes de sobrescribirla.
Bajo Unix, por ejemplo, si hemos instalado Tomcat en el directorio /opt/apache-tomcat-6.x,
deberamos copiar las clases del servlet debajo del directorio:
/opt/apache-tomcat-6.x/webapps/ROOT/

Si ejecutamos Tomcat bajo Windows y los hemos instalado en el directorio C:\Program
Files\Apache Software Foundation\Tomcat 6.0\, deberamos copiar las clases del servlet bajo el
directorio:
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ROOT

El subdirectorio webapps/ROOT/WEB-INF/classes es el directorio por defecto en el que Tomcat
buscar nuestras clases J ava. Si hemos definido que nuestros servlets pertenecen a un
paquete, deberamos seguir las reglas estndar de J ava y crear los subdirectorios apropiados
para que la J VM pueda encontrar nuestras clases, como hicimos anteriormente. Por ejemplo, si


definimos nuestro servlet en un paquete com.mycompany.myproject, entonces deberamos
tener la estructura de directorios que se ve en la siguiente figura:

Nuestras clases J ava estarn en el subdirectorio myproject.
Esto es todo lo necesario. No hay ms configuracin posterior. Siguiendo con el ejemplo
RequestDetails, intenta copiar los ficheros de la aplicacin Web en la aplicacin Web por
defecto de Tomcat.
Probar el Servlet
Para probar nuestro servlet, arranca el servidor Tomcat, abre tu navegador Web, y escribe una
URL con la siguiente forma:
http://{address}:{port}/{servletName}

Donde:
address es el nombre o direccin IP de la mquina que est ejecutando Tomcat.
Podemos usar localhost si el navegador se est ejecutando sobre la misma mquina
que Tomcat.
port es el puerto en el que escucha Tomcat. Por defecto, es el puerto 8080.
servletName es el nombre del servlet que queremos invocar. Debera corresponder al
valor contenido en las etiquetas <url-pattern></url-pattern>del fichero descriptor de
despliegue.
Por ejemplo, si Tomcat se est ejecutando en la misma mquina que el navegador y est
escuchando el puerto por defecto (8080), podemos probar nuestro servlet de ejemplo
RequestDetails (que est mapeado a la URL SampleServlet) abriendo la siguiente URL:
http://localhost:8080/SampleServlet


Observa el poco trabajo necesario para desplegar una aplicacin Web. Copiar algunos ficheros
y probar. Esta facilidad de uso la hacen posible la especificacin J ava Servlet 2.2 y el uso de
los descriptores de despliegue.

Ciclo de vida de un servlet.
En el ciclo de vida se define cmo es cargado, instanciado e inicializado, atiende peticiones de
los clientes y cmo se deja de estar en servicio. Estas tres etapas en el ciclo de vida de un
servlet se reflejan en los mtodos init, service y destroy respectivamente.





Las etapas del ciclo de vida del servlet son las siguientes:
Carga e instanciacin
El servlet container es el responsable de la carga e instanciacin de los servlets. Esta carga e
instanciacin se producen cuando arranca el servlet container o bajo demanda cuando se
necesite el servlet. Puede haber ms de una instancia de una clase Servlet en el servlet
container.
Inicializacin
Despus de la carga e instanciacin el servlet container debe inicializar el servlet antes de que
pueda atender peticiones de los clientes. En esta etapa puede leer la configuracin,
inicializar recursos costosos y realizar otras actividades.
El servlet se inicializa con una llamada a su mtodo init con un objeto que implementa la
interfaz ServletConfig. Este objeto le permite al servlet acceder a los parmetros de la
informacin de configuracin del servlet container. El objeto de configuracin le permite al
servlet acceder a un objeto que implementa la interfaz ServletContext que describe el entorno
de ejecucin del servlet.
Durante la inicializacin se pueden producir errores y en ese caso se lanzar una excepcin de
la clase UnavailableException o ServletException. En este caso la instancia del servlet no se
pondr en servicio y se eliminar del servlet container (sin llamar al mtodo destroy). Una vez
que se ha eliminado la instancia errnea se puede instanciar otra en cualquier momento,
excepto en el caso de que la instancia produjese una excepcin de la clase
UnavailableException indicando un tiempo mnimo; en este caso se ha de esperar ese tiempo
mnimo para volver a instanciar el servlet.
Manejo de peticiones
Una vez que el servlet ha sido inicializado se puede usar para atender peticiones. Las
peticiones se representan mediante un objeto de la clase ServletRequest y el servlet puede
crear una respuesta representada por una instancia de la clase ServletResponse. Estos objetos
se pasan como parmetros al mtodo service de la interfaz Servlet. En caso de que sea una
peticin HTTP el container debe proporcionar peticiones y respuestas que sean de las clases
HttpServletRequest y HttpServletResponse respectivamente.


La atencin de peticiones presenta las siguientes caractersticas:
Caractersticas Multihilo
El servlet container puede enviar mltiples peticiones de mltiples clientes por medio del
mtodo service a la vez. Esto significa que el programador ha de programar el servlet
adecuadamente para soportar la concurrencia.
Si no se quiere que el servlet tenga esta caracterstica (la de multihilo), se puede hacer que el
servlet extienda la interfaz SingleThreadModel. As se garantiza que slo se va a atender una
peticin a la vez (slo se est ejecutando un mtodo service a la vez). Para soportar este
modelo el container debe serializar las peticiones que llegan a un servlet o tener un conjunto de
servlets para atender las peticiones. Si el servlet es parte de una aplicacin distribuida el
container debe mantener un conjunto de instancias del servlet en cada mquina virtual java en
la que est la aplicacin.
Si el programador define un mtodo service (o mtodos como el doGet o doPost que ejecutan
el mtodo service) con la palabra clave syncronized, el container debe serializar las peticiones
al servlet.
Excepciones durante la atencin de peticiones
Mientras se est realizando el servicio requerido por una peticin se pueden producir
excepciones de dos clases: ServletException o UnavailableException.
Una ServletException indica que se produjo una excepcin durante la ejecucin del servicio y el
container ha de rechazar la peticin.
Si la que se produce es una excepcin de la clase UnavailableException indica que no se
puede atender la peticin de forma temporal o permanente.
Si la inhabilitacin es permanente el container debe eliminar el servlet llamando a su mtodo
destroy y eliminando la instancia. Si se inhabilita de forma temporal el container no enva
peticiones al servlet durante el tiempo de inhabilitacin, devolviendo a los clientes un mensaje
indicndolo. Otra opcin es no hacer distincin entre el tipo temporal y permanente y
considerarlos todos como permanentes.



Fin del servicio
Un servlet no se ha de mantener en servicio un determinado tiempo, si no que puede estar en
servicio desde unos segundos a varios das. Es el container el encargado de determinar la
cantidad de tiempo que un servlet est en servicio. Cuando el container lo requiera, elimina un
servlet liberando los recursos que tenga asignados y salvando su estado persistente. Para
realizar esta operacin el container llama al mtodo destroy de la interfaz Servlet.
Antes de realizar la llamada al mtodo destroy ha de esperar a que todos los threads del servlet
terminen la llamada al mtodo service o excedan un tiempo lmite previamente establecido.
Una vez que se cumpla esta condicin es cuando se llama al mtodo destroy.
Una vez que se realiza la llamada al mtodo destroy en una instancia, el container no debe
enviarle ms peticiones, si se necesita de nuevo ha de crear otra instancia para que atienda las
nuevas peticiones.
Cuando se ha acabado de ejecutar el mtodo destroy en una instancia, el container ha de
eliminar esa instancia para que sea desechada por el recolector de basura.



Contexto de un servlet.
El contexto de un servlet define el entorno en el que el servlet se est ejecutando. Esto le
permite acceder a los recursos, capturar eventos, establecer y obtener atributos de otros
servlets que se ejecutan en el mismo entorno. Para poder realizar esto el container ha de
proporcionar una implementacin de la interfaz ServletContext.
Una instancia de esta implementacin ha de ser un recurso web, y por lo tanto accesible por
medio de una URL, as es accesible a todos los servlets que se ejecuten en este entorno. En el
caso de que se trate de una aplicacin distribuida, habr una instancia por cada mquina virtual
java.
Alcance del Contexto Servlet
Hay una instancia de la interfaz ServletContext por cada aplicacin que se ejecute en un
container. Como ya se ha dicho, si se trata de una aplicacin distribuida, habr una instancia en
cada mquina virtual java en la que se ejecute la aplicacin.
Existe una instancia de la interfaz ServletContext que se asigna por defecto a los servlets que
no se desarrollen como parte de una aplicacin web, pero con el inconveniente de que no
puede formar parte de una aplicacin distribuida, es decir, slo puede estar en una mquina
virtual java.
Parmetros de inicializacin
Se pueden asociar una serie de parmetros a una aplicacin. Para acceder a ellos la clase
ServletContext proporciona dos mtodos: getInitParameter y getInitParameterNames.
Atributos del contexto
Dentro de un contexto se pueden guardar objetos a los que se accede por nombre. De esta
forma cualquier servlet que forme parte de la aplicacin puede acceder a estos objetos. Para
poder operar con los atributos la interfaz proporciona los siguientes mtodos:
setAttribute, permite almacenar un objeto con un nombre.
getAttribute, obtiene un objeto a partir del nombre.
getAttributeNames, obtiene los nombres de los objetos.
removeAttribute, borra un atributo.


Estos atributos del contexto son locales a la mquina virtual java en la que se crean. Si se
quieren compartir (en una aplicacin distribuida) han de ser definidos en una sesin, en una
base de datos o ser un J avaBean.
Recursos
La interfaz ServletContext permite acceder a recursos como ficheros HTML, GIF y J PEG
mediante los mtodos getResource y getResourceAsStream. Estos mtodos no permiten
obtener recursos dinmicos como J SP.



Objetos HttpServletRequest y
HttpServletResponse.

El request
Para encapsular la informacin de las peticiones de los clientes se ha definido una clase cuyas
instancias representan las peticiones. Se trata de la clase HttpServletRequest.
Parmetros
Los parmetros de una peticin son strings enviados por el cliente como parte de una peticin.
Los parmetros son almacenados por el servlet container como pares nombre, valor. Asociado
a un mismo nombre puede haber varios valores. Para acceder a ellos en la clase
ServletRequest se definen los siguientes mtodos:
getParameter, dado un nombre devuelve el primer valor de su array de valores.


getParameterNames, devuelve todos los nombres de los parmetros.
getParameterValues, dado un nombre devuelve un array de strings con todos los
valores asociados.
Atributos
Los atributos son objetos asociados a una peticin. Son creados por el container para expresar
informacin que de otra manera no podra expresar o son creados por un servlet para
comunicar informacin a otro servlet. Para operar con los atributos en la clase ServletRequest
se definen los mtodos getAttribute, getAttributeNames y setAttribute.
A un nombre de atributo slo puede estar asociado un valor.
Cabeceras
Para acceder a las cabeceras de una peticin HTTP se han definido los mtodos getHeader,
getHeaders y getHeaderNames en la interfaz HttpServletRequest.
Si la cabecera contiene datos enteros o fechas, se puede acceder a ellos mediante los mtodos
getIntHeader y getDateHeader respectivamente.

Path de una peticin
El path de una peticin enviada a un servlet consta de varias secciones que se obtienen de la
URI:
Path del contexto, es el path asociado con el ServletContext del que forma parte el
servlet.
Path del servlet, es la seccin que hace referencia directa al servlet.
PathInfo, es el resto del path.
Para acceder a cada una de las secciones se han definido los mtodos getContextPath,
getServletPath y getPathInfo.
Por ejemplo, en el path /catalog/lawn/index.html se distingue el ContextPath /catalog, el
ServletPath /lawn y el PathInfo /index.htm.
Para poder conocer el path real existen dos mtodos en la interfaz HttpServletRequest que
proporcionan esta informacin. Por un lado tenemos getRealPath que devuelve un String que


representa un fichero en el sistema de ficheros local. Por otro lado tenemos getPathTranslated
que devuelve el path real del pathInfo.
Cookies
En la interfaz HttpServletRequest tenemos un mtodo que permite obtener un array con las
cookies de la peticin. Este mtodo es el mtodo getCookies.
Sesiones
De HttpServletRequest tambin nos interesa el mtodo getSession(boolean crear), que nos
devuelve un objeto de tipo HttpSession y cuyo parmetro indica si debera crearse una sesin o
no para ese usuario en caso de que no exista ya. Una sesin es el mecanismo por el cual
podemos identificar una serie de iteraciones de un cliente con nuestra aplicacin, y guardar y
obtener valores que se mantengan para ese usuario durante las distintas peticiones que haga
durante la sesin.
En castellano: Un usuario pide una de nuestras pginas J SP o uno de nuestros servlets, por
ejemplo la pgina de login.
Se crea una cookie (tambin se pueden usar otros mtodos) en el navegador del usuario, con
un identificador aleatorio.
Ahora, en nuestro J SP o servlet podemos guardar valores cualquiera que podrn ser vistos por
las dems pginas J SP o servlets de nuestra aplicacin que visite el usuario. Por ejemplo
guardamos el nombre de usuario que ha introducido.
Si el usuario visita otra de nuestras pginas podemos obtener el valor que guardamos en la
sesin. Por ejemplo, podemos obtener el nombre de usuario que guardamos e imprimirlo en
la parte superior de la pgina con un "Bienvenido Zootropo".



La respuesta
El objeto respuesta encapsula toda la informacin que se le devuelve al cliente. Este objeto es
de una clase que implementa la interfaz ServletResponse.
Buffering
Por causas de eficiencia el servlet container puede tener un buffer para escribir la salida para el
cliente. En la interfaz ServletResponse existen varios mtodos para soportar esta
caracterstica:
getBufferSize, obtiene el tamao del buffer. Si an no se uso el buffer devuelve 0.
setBufferSize, este mtodo establece el tamao del buffer.
isCommited, con este mtodo se sabe si lo que hay en el buffer ha sido enviado al
cliente o no.
reset, este mtodo limpia el buffer sin que los datos que contenga se le enven al
cliente.
flushBuffer, este mtodo provoca que el contenido del buffer se enve al cliente.
El buffering se usa cuando el servlet usa un objeto ServletOutputStream o un Writer para
realizar las operaciones de escritura.
Si la respuesta se confirma y se llama al mtodo reset se produce una excepcin de la clase
IllegalStateException. En este caso el contenido del buffer no cambia.
En cuanto se llena el buffer, el container debe enviar los datos al cliente y la respuesta se
considera confirmada.
Cabeceras
Un servlet puede modificar las cabeceras HTTP de la respuesta por medio de los mtodos de
la interfaz HttpServletResponse.
Los mtodos son los siguientes:
setHeader, este mtodo establece una cabecera dado un nombre y un valor. Si ya
existe una cabecera con ese nombre se reemplazan los valores por los nuevos.


addHeader, este mtodo aade un valor a una cabecera. Si el nombre de la cabecera
an no existe se crea.

Las cabeceras contienen datos que son nmeros o fechas, siendo los mtodos para operar con
ellos, los siguientes: setIntHeader, setDateHeader, addInteHeader y addDateHeader.
Otros mtodos
En la interfaz HttpServletResponse existen otros dos mtodos de gran utilidad.
El primero de ellos es el mtodo sendRedirect. Este mtodo se usa para redirigir las cabeceras
y el contenido de la respuesta a una URL diferente a la del cliente. En caso de que la nueva
direccin sea incorrecta el mtodo lanza una excepcin de la clase IllegalArgumentException.
El segundo mtodo es el mtodo sendError, que como su nombre indica devuelve un error al
cliente, pudiendo incluir un String para incluirlo en el cuerpo.
Estos mtodos son un poco diferentes a los dems que envan datos a los clientes, porque
envan los datos inmediatamente y confirman la respuesta, por lo que s se envan datos
despus, estos se descartan, y los que haba en el buffer sin confirmar se eliminan.
Internacionalizacin
Un cliente puede solicitar un documento en un determinado lenguaje y un servlet puede
modificar los atributos de la respuesta para satisfacer al cliente. La informacin sobre el idioma
del documento se encuentra en la cabecera Content-Language del protocolo HTTP/1.1. En la
interfaz ServletResponse se encuentra el mtodo setLocale que sirve para modificar el atributo
del idioma.
Para que este mtodo funcione correctamente ha de ser llamado antes de llamar al mtodo
getWriter de la interfaz ServletResponse.
Si despus de llamar al mtodo setLocale se llama al mtodo setContentType especificando
un conjunto de caracteres, este valor sustituye al establecido por el mtodo setLocale.





Finalizacin del objeto respuesta
Existen varios eventos que indican que el servlet ha satisfecho la respuesta del cliente y ha
establecido el contenido, por lo que el objeto respuesta est finalizado. Estos eventos son:
La terminacin del servicio del servlet.
Cuando el contenido escrito en el objeto respuesta es el especificado mediante el
mtodo setContentLength.
Cuando se llama al mtodo sendError.
Cuando se llama al mtodo sendRedirect.
Cuando se finaliza el objeto respuesta se enva el contenido del buffer al cliente.



Compartir Informacin.
El mtodo de HttpSession que se utiliza para guardar objetos en la sesin es
setAttribute(String nombre, Object objeto) y el mtodo que se utiliza para obtener los objetos
que guardamos, getAttribute(String nombre). No obstante hay que tener en cuenta que los
objetos que guardamos en la sesin deben ser serializables (implementar Serializable).
Un concepto similar al de las sesiones sera el de contexto de Servlet. Este permite guardar y
recuperar valores, pero estos valores sern comunes para todos los usuarios de la aplicacin.
Se representa por un objeto ServletContext que obtenemos a partir del mtodo
getServletContext() de GenericServlet y tiene mtodos getAttribute y setAttribute al estilo de la
sesin.
Sesiones
El protocolo HTTP no tiene estado, pero es necesario para construir aplicaciones web, poder
asociar una serie de peticiones de un cliente con otras. Existen varias estrategias para
mantener una sesin, pero es complicado programarlas directamente.
La interfaz HttpSession permite al servlet container usar una aproximacin para mantener una
sesin de forma transparente.
Mecanismos para el mantenimiento de sesiones
Hay varios mecanismos para el mantenimiento de las sesiones:
Reescritura de la URL. Es lo que se utiliza cuando un cliente no acepta cookies. Este
mtodo consiste en aadir informacin al path que puede ser interpretada por el
container para asociar la peticin a una sesin. La identificacin de la sesin ha de ser
codificada en el string de la URL como un parmetro de nombre jsessionid.
Cookies. Es el mtodo ms usado y adems todos los containers deben soportarlo.
El container enva una cookie al cliente y este le devuelve la cookie en cada peticin
asociando la peticin con una sesin. El nombre de la cookie debe ser J SESSIONID.
Sesiones SSL. Se usa con el protocolo HTTPS, que a su vez utiliza tecnologa SSL
(Secure Sockets Layer) de encriptado. Este protocolo tiene un mecanismo que permite
identificar las peticiones de un cliente con una sesin. A partir de este mecanismo el
container puede obtener informacin para asociar la peticin a una sesin.


Creacin de una sesin
Como el protocolo HTTP es un protocolo basado en peticiones y respuestas, para que un
cliente se una a una sesin debe devolver la informacin al servidor indicando que se ha
establecido una sesin.
Una sesin se considera nueva si se da una de las siguientes situaciones:
El cliente no conoce la sesin.
El cliente no se une a la sesin, por lo que el container no puede asociar esta peticin
con una anterior.
Alcance de una sesin
El alcance de una sesin abarca el nivel del contexto de la aplicacin/servlet. El mecanismo
que se use para establecer la sesin puede ser compartido entre contextos, pero el objeto
(instancia de una implementacin de la clase HttpSession) y sus atributos no se comparten
entre contextos.
Atributos de una sesin
Un servlet puede poner un objeto atributo en una implementacin de la clase HttpSession, al
que accede por nombre. Cualquier objeto atributo de una sesin establecido por un servlet,
puede ser accedido por otro servlet que pertenezca al mismo ServletContext y que adems
maneje una peticin que sea parte de la misma sesin.
A veces es necesario que se notifiquen eventos relacionados con estos objetos atributo.
Son eventos como la insercin en la sesin y su eliminacin. En este caso se puede usar una
implementacin de la interfaz HttpSessionBindingListener. Esta interfaz define una serie de
mtodos para que se notifique la insercin y eliminacin de un atributo en una sesin:
valueBound, este mtodo se llama antes de que est disponible.
valueUnbound, se llama despus de que el atributo sea eliminado de la sesin.

Timeouts de la sesin
En el protocolo HTTP no hay una seal explcita para que el cliente indique que ya no est
activo. El nico mecanismo para determinar si un cliente est activo o no es por medio del
control del tiempo que el cliente est inactivo.


El tiempo mximo que un cliente puede estar inactivo se define en el servlet container y se
puede obtener llamando al mtodo getMaxInactiveInterval de la interfaz HttpSession. Adems
este tiempo puede ser cambiado mediante un mtodo de la misma interfaz, se trata del mtodo
setMaxInactiveInterval. Si se establece un intervalo de -1 segundos, entonces la sesin nunca
termina por el paso de un intervalo de tiempo.
Fecha del ltimo acceso
Por medio del mtodo getLastAccessedTime de la interfaz HttpSession se puede
determinar la fecha del ltimo acceso a la sesin antes de la peticin actual. Una sesin se
considera accedida cuando se atiende una peticin que es parte de la sesin.
Cuestiones sobre las sesiones
Varios hilos de un servlet atendiendo peticiones han de tener un acceso activo a un nico
objeto sesin al mismo tiempo. Es responsabilidad del programador sincronizar los accesos a
los recursos de la sesin.
Cuando se trata de una aplicacin distribuida, todas las peticiones que son parte de una sesin
slo pueden ser manejadas por una mquina virtual java. Adems los objetos de una sesin
han de implementar la interfaz Serializable.
Debido a que las cookies y los certificados SSL son controlados por el navegador y no se
asocian con ninguna ventana, todas las ventanas de una aplicacin cliente que envan
peticiones al servlet, deben pertenecer a la misma sesin.

Enva tus consultas a los foros!
Aqu es cuando debes sacarte todas las dudas
haciendo consultas en los foros
correspondientes

1 2 Java Servlets

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

1 2 Java Servlets

Diunggah oleh

Hak Cipta:

Format Tersedia

Curso: "Java EE y Frameworks" 2013

Anda mungkin juga menyukai