Servlets para Fin de Sesion Hoy

Introducción
• Necesidad de mecanismos para desarrollar

“aplicaciones web”  contenido dinámico
• Cuando escribes una URL en tu navegador:
– El navegador establece una conexión TCP/IP con el
servidor
– El navegador envía una petición al servidor
– El servidor devuelve una respuesta al cliente
– El servidor cierra la conexión
• Los mensajes intercambiados entre el cliente y el
servidor son HTTP
Tecnología Servlet
• Piedra angular del desarrollo de aplicaciones
web en Java
– Los JSPs son de hecho servlets “disfrazados”
Características de los Servlets
• Pensados para reemplazar a los CGIs
– Cada petición de un cliente hacía al servidor lanzar
un nuevo proceso con el programa CGI
• No es la única tecnología disponible:
– ASP.NET
– PHP (plataforma LAMP)
Arquitectura
• Servlet Container = servidor web capaz de
ejecutar servlets
• En una aplicación JSP, el contenedor se
corresponde a un JSP container.
HTTP Request Servlet Container Servlet

Browser HTTP Server
HTTP Response
Contenido Estático
Funcionamiento de un Servlet
Recibir
Petición
¿Está el
Servidor NO
Cargado?
SÍ
¿Es el
servidor NO Cargar Servlet
reciente?
SÍ
Procesar Petición
Enviar
Respuesta
Contenedor Tomcat
• El contenedor de Servlets más popular
• Open source, disponible en:
http://jakarta.apache.org/tomcat/
Instalando Tomcat 5
• Requisitos:
– Haber instalado Java
• Extraer fichero:
downloads\Tomcat5.5\jakarta-tomcat-
5.5.7.zip
• Crear las siguientes variables de entorno, por medio
de Panel de Control->Sistema-
>Avanzado->Variables de Entorno:
– TOMCAT_HOME=<TOMCAT_INSTALL_DIR>
6 Pasos Para Crear tu Primer Servlet
1. Crear una estructura de directorios bajo

Tomcat para tu aplicación
2. Escribir el código del servlet
3. Compilar el código
4. Crear un descriptor de explotación
(deployment descriptor)
5. Ejecutar Tomcat
6. Invocar el servlet desde un navegador
Crear directorio bajo Tomcat para tu
aplicación
• El directorio %TOMCAT_HOME%/webapps es dónde cuelgas tus

aplicaciones
• Una aplicación web es un conjunto de servlets y otros recursos
instalados bajo el espacio URL de un servidor
• Pasos:
1. Crear un directorio bajo webapps con el nombre de tu aplicación
‘myapp’, que aparecerá en la url a tu aplicación
2. Crear el directorio WEB-INF debajo de ‘myApp’
• Crear subdirectorio clases
• Crear subdirectorio lib
• Podéis hacer copy/paste del contenido del directorio
examples\servlets\ej1_holamundo_servlet bajo
%TOMCAT_HOME\webapps\myapp
– Vamos a reutilizar continuamente el contexto
myapp
Escribir el Código del Servlet
// HelloWorldExample.java
import java.io.*;
import java.text.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorldExample extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
ResourceBundle rb =
ResourceBundle.getBundle("LocalStrings",request.getLocale());
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head>");
String title = rb.getString("helloworld.title");
out.println("<title>" + title + "</title>");
out.println("</head>");
out.println("<body bgcolor=\"white\">");
out.println("<h1>" + title + "</h1>");
out.println("</body>");
out.println("</html>");
}
}
Compilar el Código
• Guardar el código en %TOMCAT_HOME
%\webapps\myapp\WEB-INF\classes
• Compilar el código:
javac –classpath %TOMCAT_HOME
%\common\lib\servlet-api.jar
HelloWorldExample.java
Crear el web.xml
• Nombre recibido por el deployment descriptor
– Debe colocarse en el directorio WEB-INF
• web.xml es un documento XML que tiene
como elemento raíz: <web-app>
• Se pueden encontra n elementos <servlet>
que cuelgan de él
Crear el web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>Servlet 2.4 Examples</display-name>
<description>
Servlet 2.4 Examples.
</description>
<servlet>
<servlet-name>HelloWorldExample</servlet-name>
<servlet-class>HelloWorldExample</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorldExample</servlet-name>
<url-pattern>/HelloWorldExample</url-pattern>
</servlet-mapping>
</web-app>
Ejecutar el Código
• Arrancar Tomcat si es necesario, mediante el
comando: %TOMCAT_HOME
%\bin\catalina.bat run
• Invocar al servlet:
http://localhost:8080/myapp/Hel
loWorldExample
Resultado de Ejecutar Servlet
Servlets: Jerarquía
• La jerarquía de clases java es...
• Únicamente hay que hacer polimorfismo de

los métodos que se quieran tratar.
Las APIs
• Dos paquetes permiten la programación de
servlets:
– javax.servlet
– javax.servlet.http
• Revisar documentación:
– Arrancar Tomcat
– Visitar: http://localhost:8080
Servlets: Ciclo de vida
• Ciclo de vida de un servlet:
Servlets: Ciclo de vida
• Viene dado por tres métodos: init, service y
destroy
• INICIALIZACIÓN: Una única llamada al método
“init” por parte del servidor. Incluso se pueden recoger
unos parametros concretos con “getInitParameter”
de “ServletConfig”.
• SERVICIO: una llamada a service() por cada
invocación al servlet
– ¡Cuidado! El contenedor es multihilo
• DESTRUCCIÓN: Cuando todas las llamadas desde el
cliente cesen o un temporizador del servidor así lo indique.
Se usa el método “destroy”
• Revisar documentación de la clase
javax.servlet.Servlet
Demostrando el Ciclo de Vida
// examples\servlets\ej2_ciclovida_servlet
import java.io.IOException;
public class CicloVidaServlet implements Servlet {
public void init(ServletConfig config) throws ServletException {
System.out.println("init");
}
public void service(ServletRequest request, ServletResponse response)
throws ServletException, IOException {
System.out.println("service");
}
public void destroy() {
System.out.println("destroy");
}
public String getServletInfo() {
return null;
}
public ServletConfig getServletConfig() {
return null;
}
}
Servlets: Operaciones duraderas
• Respuestas a peticiónes de clientes que
requieran de un tiempo de proceso muy largo.
• Puede que el servlet deba destruirse y estas
operaciones aun no hayan concluido.
• Es responsabilidad del programador
encargarse de su gestión.
• Necesitaremos por tanto:
– Mantener un seguimiento de las tareas (threads) que se
estén ejecutando en el método “service”
– Proporcionar una finalización correcta haciendo que los
procesos largos que aun no hayan concluido puedan
terminar correctamente en el método “destroy” del
servlet.
– En ciertos casos poder terminar los procesos que aun
siguen en ejecución si es necesario.
• Posible solución: Contador

public ShutdownExample extends HttpServlet {
private int serviceCounter = 0;
private Object lock = new Object();
protected void enteringServiceMethod() {
synchronized(lock) { serviceCounter++; }
}
protected void leavingServiceMethod(){
synchronized(lock) {
serviceCounter--;
if (serviceCounter == 0 && isShuttingDown()) notifyAll();
}
}
protected int numServices() {
synchronized(lock) { return serviceCounter; }
}
protected void service(HttpServletRequest req, HttpServletResponse resp)
enteringServiceMethod();
try { super.service(req, resp); }
finally { leavingServiceMethod(); }
}
• Falta indicar la terminación.

public ShutdownExample extends HttpServlet {
private boolean shuttingDown;
protected void setShuttingDown(boolean flag) {
shuttingDown = flag;
}
protected boolean isShuttingDown() {
return shuttingDown;
}
synchronized(lock) {
if (numServices() > 0) {
setShuttingDown(true);
}
while(numServices() > 0) {
try { wait(); }
catch (InterruptedException e) { }
}
}
}
}
Recuperando Configuración
• Recuperando información de configuración del fichero web.xml
<servlet>
<servlet-name>ConfigDemoServletExample</servlet-name>
<servlet-class>ConfigDemoServlet</servlet-class>
<init-param>
<param-name>adminEmail</param-name>
<param-value>dipina@ilargi.org</param-value>
</init-param>
<init-param>
<param-name>adminContactNumber</param-name>
<param-value>6542214213</param-value>
</init-param>
</servlet>
Recuperando Configuración
• Recuperando información de configuración del fichero web.xml, revisar ejemplo
examples\servlets\ej3_configinfo_servlet
public class ConfigDemoServlet implements Servlet {

ServletConfig cfg;
this.cfg = config;
Enumeration parameters = config.getInitParameterNames();
while (parameters.hasMoreElements()) {
String parameter = (String) parameters.nextElement();
System.out.println("Parameter name : " + parameter);
System.out.println("Parameter value : " +
config.getInitParameter(parameter));
}
}
// ...
}
Contexto del Servidor
• ServletContext representa el entorno donde se ejecuta el servidor, es
decir, el Servlet Container
– Se puede obtener una referencia a él mediante el método
ServletConfig.getServletContext()
– Algunos métodos que se pueden utilizar son:
• getMajorVersion  de la Servlet API soportada por el contenedor
• getMinorVersion
• setAttribute  guarda un objeto en el ServletContext
• getAttributeNames
• getAttribute
• removeAttribute
• A través del contexto de un servlet se puede compartir estado entre varios
servlets.
• Revisar ejemplo
examples\servlets\ej4_contextinfo_servlet
Contexto del Servidor
ServletConfig servletConfig;

servletConfig = config;
}

ServletContext servletContext = servletConfig.getServletContext();

Enumeration attributes = servletContext.getAttributeNames();
while (attributes.hasMoreElements()) {
String attribute = (String) attributes.nextElement();
System.out.println("Attribute name : " + attribute);
System.out.println("Attribute value : " +
servletContext.getAttribute(attribute));
}
System.out.println("Major version : " + servletContext.getMajorVersion());

System.out.println("Minor version : " + servletContext.getMinorVersion());
System.out.println("Server info : " + servletContext.getServerInfo());
}
Peticiónes y Respuestas
• En el método service() los parámetros:
– ServletRequest representa la petición del cliente y
– ServletResponse la respuesta del servidor
• ServletRequest tiene los siguientes métodos:
– getParameterNames
– getParameter
– getRemoteAddress
– getRemoteHost
• ServletResponse tiene entre otros el método:
– getWriter
• Revisar
examples\servlets\ej5_requestresponse_servlet
Ejemplo ServletRequest y
ServletResponse

out.println("<HTML>");
// ...
out.println("<BR>Server Port: " + request.getServerPort());
out.println("<BR>Server Name: " + request.getServerName());
out.println("<BR>Protocol: " + request.getProtocol());
out.println("<BR>Character Encoding: " + request.getCharacterEncoding());
out.println("<BR>Content Type: " + request.getContentType());
out.println("<BR>Content Length: " + request.getContentLength());
out.println("<BR>Remote Address: " + request.getRemoteAddr());
out.println("<BR>Remote Host: " + request.getRemoteHost());
out.println("<BR>Scheme: " + request.getScheme());
Enumeration parameters = request.getParameterNames();
while (parameters.hasMoreElements()) {
String parameterName = (String) parameters.nextElement();
out.println("<br>Parameter Name: " + parameterName);
out.println("<br>Parameter Value: " +
request.getParameter(parameterName));
}
Enumeration attributes = request.getAttributeNames();
while (attributes.hasMoreElements()) {
String attribute = (String) attributes.nextElement();
out.println("<BR>Attribute name: " + attribute);
out.println("<BR>Attribute value: " + request.getAttribute(attribute));
}
out.println("</BODY>");
out.println("</HTML>");
}
Clase GenericServlet
• El uso de la interfaz Servlet tiene dos
inconvenientes:
– Hay que proveer implementaciones de los cinco
métodos de Servlet
– Hay que cachear la referencia a
ServletConfig pasada como parámetro
• La clase GenericServlet provee una
implementación vacía de los 5 métodos de
Servlet y recuerda ServletConfig
Ejemplo GenericServlet
import java.io.IOException;
import java.io.PrintWriter;
public class SimpleServlet extends GenericServlet {


out.println("<HEAD>");
out.println("<TITLE>");
out.println("Extending GenericServlet");
out.println("</TITLE>");
out.println("</HEAD>");
out.println("<BODY>");
out.println("Extending GenericServlet makes your code simpler.");
}
}
Paquete javax.servlet.http
• Normalmente siempre vamos a trabajar con él cuando
programemos servlets.
• Sus miembros y métodos son más convenientes y
ofrecen más funcionalidad
• Principalmente vamos a tratar con tres clases:
– HttpServlet
– HttpServletRequest
– HttpServletResponse
HttpServlet
• Hereda de GenericServlet
• Tiene 6 métodos doXXX que son invocados cada vez
que el correspondiente comando HTTP es recibido:
– doPost
– doPut
– doGet
– doDelete
– doOptions
– doTrace
Servlets: Explicación de métodos HTTP
• GET: Paso de parámetros en la propia URL de acceso al

servicio o recurso del servidor. Método “doGet”
GET /query.html?keyword='diego' HTTP/1.1
Accept: image/gif, image/x-xbitmap,
image/jpeg, image/pjpeg, application/vnd.ms-
excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-
flash, */*
Accept-Language: es,eu;q=0.7,en-gb;q=0.3
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; .NET CLR 1.1.4322)
Host: localhost:9999
Connection: Keep-Alive
Servlets: Explicación de métodos HTTP
• POST: Lo mismo que GET pero los parámetros van en línea aparte dentro del cuerpo de
la petición. El manejo es idéntico pero a través del método “doPost”.
POST /cgi-bin/search.sh HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Referer: http://localhost:9999/search.html
Accept-Language: es,eu;q=0.7,en-gb;q=0.3
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
.NET CLR 1.1.4322)
Host: localhost:9999
Content-Length: 13
Connection: Keep-Alive
Cache-Control: no-cache
keyword=diego
Servlets: Métodos
• Por defecto retornan BAD_REQUEST(400)
• Son llamados desde el método “service”.
• Reciben interfaces instanciadas:
– “HttpServletRequest” para manejo de la
informacion enviada por el usuario.
– “HttpServletResponse” para poder enviar
una respuesta en forma de pagina web.
Servlets: Respondiendo en HTML
• 2 pasos:
– Indicar una cabecera de respuesta de contenido (antes de
cualquier tipo de respuesta)
• Una manera es usando el método “setHeader” de
“HttpServletResponse”.
• Al ser un proceso tan común existe un método que nos lo soluciona
directamente: “setContentType” de
– Crear y enviar código HTML válido.
• Revisar
examples\servlets\ej6_dogetdopost_se
rvlet
Ejemplo doGet() y doPost()
// compile: javac -classpath %TOMCAT_HOME%\common\lib\servlet-api.jar
DoGetDoPostServlet.java
import java.io.*;
public class DoGetDoPostServlet extends HttpServlet {

public void doGet(HttpServletRequest request,
out.println("<TITLE>The GET method</TITLE>");
out.println("The servlet has received a GET. " +
"Now, click the button below.");
out.println("<BR>");
out.println("<FORM METHOD=POST>");
out.println("<INPUT TYPE=SUBMIT VALUE=Submit>");
out.println("</FORM>");
}
Ejemplo doGet() y doPost()
public void doPost(
HttpServletRequest request, HttpServletResponse response)
out.println("<TITLE>The POST method</TITLE>");
out.println("The servlet has received a POST. Thank you.");
}
}
Servlets: Recogiendo la información de
usuario.
• 2 formas de envío de información:
– En la línea URL mediante una ‘?’
– En una línea separada.
• En los antiguos CGIs el parseo era muy
complejo. En Servlets usar
“getParameter” de
“HttpServletRequest” que devuelve “”
(si no hay valor) o null (si no existe).
usuario
• Si el parametro tiene mas de un valor se usa

“getParameterValues” de “HttpServletRequest”
que devuelve un array de strings.
• Los nombres de los parametros son accesibles mediante
“getParameterNames” de “HttpServletRequest”
que devuelve un Enumeration de strings.
• Se puede leer la línea directamente con “getReader” o
“getInputStream” de “HttpServletRequest”.
• Revisar:
examples\servlets\ej7_listparams_servlet
Listando Parámetros Recibidos
PruebaServlet.java
import java.io.*;
import java.util.*;
public class PruebaServlet extends HttpServlet {

public void doGet(HttpServletRequest request, HttpServletResponse
response)
out.println("<TITLE>Obtaining the Parameter</TITLE>");
out.println("The request's parameters are:<BR>");
Listando Parámetros Recibidos
Enumeration enumeration = request.getParameterNames();
while (enumeration.hasMoreElements()){
String parameterName = (String) enumeration.nextElement();
out.println(parameterName + ": " +
request.getParameter(parameterName) + "<BR>" );
}
out.println("<FORM METHOD=GET>");
out.println("<BR>First Name: <INPUT TYPE=TEXT NAME=FirstName>");
out.println("<BR>Last Name: <INPUT TYPE=TEXT NAME=LastName>");
out.println("<BR><INPUT TYPE=SUBMIT VALUE=Submit>");
out.println("</FORM>");
}
}
usuario
• Cabeceras: Además de la información de la línea de
petición, datos añadidos opcionales (excepto
“Content-Length” en los métodos POST).
Accept Los tipos del formato MIME que acepta el navegador cliente.
Accept-Charset Los sets de caracteres que el navegador cliente espera.
Accept-Encoding Las codificaciónes de datos (por ejemplo gzip) que el
navegador cliente soporta y conoce. Así el servlet puede consultar
explícitamente información de codificación y así aprovechar las ventajas
de HTML gzipeado indicándolo en la cabecera de respuesta Content-
Encoding.
usuario
Accept-Language El lenguaje que el navegador cliente espera.
Authorization Información de autentificación, que generalmente se crea
como respuesta a una cabecera WWW Authenticate enviada desde el
servidor.
Connection Indica si se va a usar conexión persistente. Si un servlet recibe
el valor Keep-Alive o una petición con una línea indicando HTTP 1.1
podrá hacer uso de las ventajas que estas ofrecen ahorrando tiempo en
páginas con muchos elementos pequeños como imágenes o applets. El
servlet ha de indicar el tamaño del contenido a enviar como respuesta
mediante la cabecera Content-Length. Para ello se puede usar la clase
ByteArrayOutputStream y al final enviar todos los datos.
Content-Length Usada en los mensajes POST para indicar el tamaño
de los datos.
usuario
Cookie Una cabecera muy importante para envío de información.
From La dirección de email del cliente.
Host El host y el puerto sacados de la URL original.
If-Modified-Since Para indicar que solo han de enviarse documentos
posteriores al actual. Si no es así, se envía una respuesta 304 "Not
Modified".
Pragma Si contiene el valor no-cache indica que el servidor ha de enviar
una nueva copia del documento.
Referer La URL de la página que contenía el link que el cliente siguió para
llegar a la pagina actual.
User-Agent El tipo de navegador que usa el cliente. Es útil si se va enviar
contenido especifico para un tipo de navegador.
UA-Pixels, UA-Color, UA-OS, UA-CPU Cabeceras no estándar enviadas
desde IE indicando el tamaño de pantalla, la profundidad de color, el SO y
el tipo de cpu usado en el cliente.
usuario
• Los métodos para acceder a estas cabeceras son:

– “getHeader” de “HttpServletRequest” que
devuelve un String.
– “getHeaderNames” de “HttpServletsRequest”
que devuelve un Enumeration de strings.
• Puede que algunos clientes recojan información de un
servlet. Para ello se puede hacer polimorfismo del
método “getServletInfo” que debe devolver un
String.
• Revisar:
examples\servlets\ej8_listheaders_ser
vlet
Listando Cabeceras
• http://localhost:8080/myapp/servlet/PruebaServlet
PruebaServlet.java
import java.io.*;
import java.util.*;
public class PruebaServlet extends HttpServlet {

public void doGet(HttpServletRequest request, HttpServletResponse
response)
Enumeration enumeration = request.getHeaderNames();
while (enumeration.hasMoreElements()) {
String header = (String) enumeration.nextElement();
out.println(header + ": " + request.getHeader(header) + "<BR>");
}
}
}
Servlets: Políticas de acceso concurrente
(threading)
• Los servlets están diseñados para soportar múltiples
accesos simultáneos por defecto.
• El problema puede surgir cuando se hace uso de un
recurso compartido.
• Se exponen soluciones a poder considerar:
– Hacer que el servlet permita un único acceso cada vez.
– Hacer que el recurso sea el que posea la política de acceso
concurrente.
Servlets: Políticas de acceso concurrente
(threading)
• Para hacer que el servlet trate a un cliente cada
vez, únicamente hay que hacer que nuestra
clase, además de heredar de
“HttpServlet”, implemente la interfaz
“SingleThreadModel” que es una interfaz
sin métodos.
Servlets: Accediendo a variables CGI
• Una colección de información derivada de muchos
elementos que es accesible a través del objeto
“HttpServletRequest” y el contexto del
servlet.
• Estas variables pueden ser proporcionadas por:
– La petición (la línea de petición o parte del URI o las
cabeceras).
– Del socket en sí (la IP).
– De los parámetros de instalación del servidor web (los
mapeos de las URL a los paths).
AUTH_TYPE
El esquema especificado si se recibe una cabecera Authorization. Puede ser basic o
digest.
request.getAuthType()
CONTENT_LENGTH
Solo para peticiónes POST e indica el numero de bytes enviados.
String.valueOf(request.getContentLength()) o
request.getContentLength
CONTENT_TYPE
El tipo de MIME.
request.getContentType()
DOCUMENT_ROOT
La ruta el directorio http://host/
getServletContext().getRealPath("/")
http_XXX_YYY
Acceso a librerías HTTP
request.getHeader("Xxx-Yyy")
PATH_INFO
Información de path añadida a la petición. De todas formas no tiene por que ser tratada de
manera independiente (no como en los CGIs).
request.getPathInfo()
PATH_TRANSLATED
Información de path de mapeo en el las rutas reales del servidor.
request.getPathTranslated()
QUERY_STRING
Para las peticiónes GET. Es un string aun codificado en URL. Mejor usar
request.getParameter
request.getQueryString()
REMOTE_ADDR
La IP del cliente.
request.getRemoteAddr()
REMOTE_HOST
El nombre de dominio del cliente. Si no se puede devuelve la IP.
request.getRemoteHost()
REMOTE_USER
La parte de usuario de una cabecera Authorization.
request.getRemoteUser()
REQUEST_METHOD
El tipo de petición: GET, POST, HEAD, PUT, DELETE, OPTIONS, o TRACE.
request.getMethod()
SCRIPT_NAME
El path al servlet
request.getServletPath()
SERVER_NAME
El nombre del servidor web
request.getServerName()
SERVER_PORT
El numero del puerto donde el servidor web esta “escuchando”.
Equivalente a String.valueOf(request.getServerPort()) Pero directamente…
request.getServerPort()
SERVER_PROTOCOL
Nombre y versión usados en la línea de petición (e.i. HTTP/1.0 or HTTP/1.1).
request.getProtocol()
SERVER_SOFTWARE
Información de identificación del servidor web
getServletContext().getServerInfo()
Servlets: Respondiendo: Códigos de
estado
• La respuesta esta compuesta por:
– Una línea de estado (200 OK).
– Cabeceras de respuesta.
– Una línea en blanco.
– Un documento.
• La línea de estado indica la versión del protocolo http
y un código de estado para indicar diferente
información al cliente:
– Enviar al usuario a otros enlaces.
– Indicar que el contenido es una imagen, PDF...
– Requerir un password.
estado
• La línea de estado consta de:

– Versión del protocolo HTTP: La suministra el servidor.
– El código de estado: Lo podemos indicar nosotros. Usar
el método “setStatus” de
– Un mensaje: Suele estar relacionado con el código de
estado.
• El código debe indicarse antes de cualquier acceso
al PrintWriter.
Ejemplo HTTP Response
HTTP/1.1 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 09:23:24
GMT
Content-Length: 6821
Connection: close
Content-Type: text/html
Cuerpo de la respuesta ...

estado
• Aunque “setStatus” es la manera más flexible,
hay unos códigos muy comunes y unos métodos para
usarlos:
– “sendError” envía un mensaje de error 404.
– “sendRedirect” que se usa para enviar un mensaje 302
conjuntamente con la cabecera de respuesta “Location”
indicando la nueva URL.
• Es importante conocer la versión de protocolo HTTP
soportado con “getProtocol” de
“HttpServletRequest”.
estado
100
Continue
Continuar con la petición parcial. (HTTP 1.1)
101
Switching Protocols
El servidor debera responder con la cabecera Upgrade y asi cambiar de protocolo. (HTTP 1.1)
200
OK
Todo correcto. Por defecto en los servlets.
201
Created
El servidor ha creado un documento. En la cabecera Location se incluye la URL.
202
Accepted
La petición ha sido aceptada pero el procesamiento no ha terminado.
estado
203
Non-Authoritative Information
El documento ha sido devuelto correctamente pero alguna cabecera es incorrecta (HTTP 1.1)
204
No Content
No hay nuevo documento. El cliente debe presentar el actual.
205
Reset Content
No hay nuevo documento pero el cliente debe refrescar el actual. Para resetear las variables CGI de los
formularios (HTTP 1.1)
206
Partial Content
El cliente envio una petición parcial con una cabecera Range y el servidor la ha rellenado. (HTTP 1.1)
300
Multiple Choices
El documento que se ha solicitado se puede encontrar en múltiples sitios. La preferida o por defecto del
servidor se ha de indicar en la cabecera Location.
estado
301
Moved Permanently
El documento solicitado está en otro sitio. Se indica la URL en la cabecera Location. El navegador
debería ir directamente.
302
Found
Similar a 301, pero la nueva URL debe entenderse como temporal. "Moved Temporarily" en HTTP 1.0, con
la constante SC_MOVED_TEMPORARILY de HttpServletResponse, (no SC_FOUND). Tambien se
puede usar el método directo response.sendRedirect(url).
303
See Other
Lo mismo que 301/302. (HTTP 1.1)
304
Not Modified
Cuando se determina que el cliente hace una petición condicional y se quiere indicar que el documento que
actualmente posee es el correcto (e.i. como respuesta a una cabecera If-Modified-Since).
305
Use Proxy
El documento solicitado debería ser accedido por el proxy indicado en la cabecera Location. (HTTP 1.1)
estado
307
Temporary Redirect
Identico a 302. No hay una variable en HttpServletResponse. (HTTP 1.1)
400
Bad Request
petición con sintaxis errónea.
401
Unauthorized
El cliente intento acceder a una pagina protegida con password sin la autorizacion necesaria. La respuesta
incluye una cabecera WWW-Authenticate para que el cliente introduzca los datos en un dialogo que
envia sus datos en la cabecera Authorization.
403
Forbidden
El recurso no esta disponible por un error en el servidor (permisos, acceso erroneo…).
404
Not Found
El recurso no pudo ser accedido. Posee un método propio HttpServletResponse:
sendError(message).
estado
405
Method Not Allowed
El método de petición (GET, POST, HEAD, DELETE, PUT, TRACE, etc.) no es permitido para el recurso
solicitado. (HTTP 1.1)
406
Not Acceptable
Incompatibilidad de tipo MIME. (HTTP 1.1)
407
Proxy Authentication Required
Lo mismo que 401, pero se obliga a usar una cabecera Proxy-Authenticate por parte del servidor.
(HTTP 1.1)
408
Request Timeout
El cliente tardo demasiado en enviar una petición. (HTTP 1.1)
409
Conflict
Generalmente en método PUT. Suele enviarse si se ha solicitado una versión incorrecta de un recurso.
(HTTP 1.1)
estado
410
Gone
El documento no esta disponible. La diferencia con 404 es que tiene carácter temporal. (HTTP 1.1)
411
Length Required
El servidor no puede procesar la petición si el usuario no envía una cabecera Content-Length. (HTTP
1.1)
412
Precondition Failed
Alguna precondición especificada en las cabeceras de petición era falsa. (HTTP 1.1)
413
Request Entity Too Large
El documento solicitado es mayor de lo que el servidor esta dispuesto a gestionar. Si el servidor estará
dispuesto de gestionarlo mas tarde deberá incluir una cabecera de respuesta Retry-After. (HTTP 1.1)
414
Request URI Too Long
La URL es demasiado larga. (HTTP 1.1)
estado
415
Unsupported Media Type
La petición esta en un formato desconocido. (HTTP 1.1)
416
Requested Range Not Satisfiable
El cliente introdujo una cabecera Range inadecuada en su petición. (HTTP 1.1)
417
Expectation Failed
El valor de la cabecera de petición Expect no se ha podido contrastar. (HTTP 1.1)
500
Internal Server Error
Un mensaje genérico para indicar que el servidor está confuso.
501
Not Implemented
El servidor no posee la funcionalidad para completar la petición. Por ejemplo si el usuario ha hecho una
petición PUT que el servlet no es capaz de procesar.
502
Bad Gateway
Usado por servidores que funcionan como proxies o puertas de enlace para indicar que recibió una respuesta
incorrecta por el servidor remoto.
estado
503
Service Unavailable
El servidor no puede responder por mantenimiento o colapso de conexiones. Se puede enviar
conjuntamente a una cabecera Retry-After.
504
Gateway Timeout
Usado por servidores que funcionan como proxies o puestas de enlace para indicar que no
recibido respuesta del servidor remoto en un tiempo adecuado. (HTTP 1.1)
505
HTTP Version Not Supported
El servidor no es capaz de responder a la version del protocolo http indicado en la petición.
(HTTP 1.1)
Servlets: Respondiendo: Cabeceras de
respuesta
• Un componente más en la línea de estado.
• Íntimamente ligadas con los códigos de estado.
– Especificar cookies
– Suministrar la fecha de modificación (para la caché)
– Instruir al navegador sobre la recarga de la página después
de un intervalo designado
– Decir cuanto tiempo va a estar el fichero usando
conexiones persistentes
– ...
respuesta
• El método más general para indicar una
cabecera de respuesta es “setHeader” de
“HttpServletResponse” y recibe 2
strings:
1. El nombre de la cabecera.
2. El valor de la cabecera.
• Antes de usar PrintWriter.
Servlets: Respondiendo: Cabeceras de respuesta
• Existen 2 métodos para cabeceras relacionadas

con:
– FECHAS: “setDateHeader” para ahorrar el
tener que pasar una fecha Java (Date) a
milisegundos.
– ENTEROS: “setIntHeader” para ahorrar el
tener que pasar un entero a String.
respuesta
• Se puede consultar si una cabecera ya ha sido

indicada en la respuesta mediante el método
“containsHeader”.
• Para añadir un valor a una cabecera que ya
haya sido seleccionada, se usan los métodos
“addHeader”, “addDateHeader” y
“addIntHeader”.
respuesta
• "HttpServletResponse" también suministra

unos métodos para especificar cabeceras comunes:
– "setContentType" selecciona la cabecera Content-
Type.
– "setContentLength" selecciona la cabecera
Content-Length, útil si el navegador soporta
conexiones HTTP persistentes (keep-alive).
– "addCookie" selecciona un cookie (no existe el
correspondiente setCookie, ya que es normal que haya
varias líneas Set-Cookie).
– "sendRedirect" selecciona la cabecera Location y
el código de estado 302.
respuesta
Allow
Indica los métodos que soporta el servidor
Content-Encoding
Indica el método usado para codificar el documento. El usar compresión puede reducir el
tamaño de los documentos pero antes es mejor asegurarse que la compresión esta soportada
usando la cabecera Accept-Encoding (e.i. request.getHeader("Accept-
Encoding")).
Content-Length
Indica el numero de bytes que se están enviando. Solo es necesaria si se están usando
conexiones http persistentes (sep-alive). Lo mas sencillo es escribir en un
ByteArrayOutputStream, luego ver el tamaño e indicarlo en Content-Length y al
final enviarlo con byteArrayStream.writeTo(response.getOutputStream()).
Content-Type
Indica el tipo de codificación MIME del documento. Por defecto es text/plain, por lo que
se suele indicar text/html. Existe un método para ello en HttpServletResponse que
es setContentType.
Date
Indica la hora actual. Hay que usar el método setDateHeader.
respuesta
Expires
Indica el tiempo en el que el contenido debe considerarse no valido y por lo tanto no
introducirlo en la cache.
Last-Modified
Indica cuándo cambio el documento por última vez. El cliente puede preguntar por ello
usando la cabecera de petición If-Modified-Since que se trata como una GET
condicional y se responde con Last-Modified si la fecha es posterior. En otro caso se
envia 304 (Not Modified) como estado. Usar setDateHeader.
Location
Indica la URL donde el cliente debe ir. Se suele usar con el estado 302 y el método
sendRedirect de HttpServletResponse.
Server
Indica el tipo de servidor. No lo suele indicar el servlet sino el propio servidor web.
Set-Cookie
Indica la cookie asociada a la página. Es recomendable no usar
response.setHeader("Set-Cookie", ...), y en su defecto addCookie de
HttpServletResponse.
respuesta
Refresh
Indica cuándo debería pedir el navegador una página actualizada. En lugar de recargar la
página actual, podemos especificar otra página a cargar mediante
setHeader("Refresh", "5; URL=http://host/path"). Se suele seleccionar
mediante la cabecera HTML <META HTTP-EQUIV="Refresh" CONTENT="5;
URL=http://host/path"> en la sección HEAD, mejor que una cabecera explícita desde
el servidor. Esto es porque la recarga o el reenvio automático es algo deseado por los autores
de HTML que no tienen accesos a CGI o servlets. Pero esta cabecera significa "Recarga esta
página o ve a URL especificada en n segundos" y no significa "recarga esta página o ve la
URL especificada cada n segundos". Por eso tenemos que enviar una cabecera Refresh cada
vez. De todas formas no es una cabecera oficial del HTTP 1.1, pero es una extensión
soportada por Netspace e Internet Explorer
WWW-Authenticate
Indica el tipo de autorización y dominio que debería suministrar el cliente en su cabecera
Authorization. Esta cabecera es necesaria en respuestas que tienen una línea de estado 401
(Unauthorized). (e.i. response.setHeader("WWW-Authenticate", "BASIC
realm=\"executives\"")).
Servlets: Acceso a recursos
• ACCEDER A RECURSOS DEL SERVIDOR
– Posibilidades:
1. Hacer que el servlet haga una petición HTTP.
2. Pedir el recurso mediante el "RequestDispatcher".
– Para acceder al RequestDispatcher hay que
recoger el contexto del servlet mediante el método
“getServletContext”.
– Seguidamente debemos acceder al recurso:

ServletContext sc = getServletContext();
RequestDispatcher rd = sc.getRequestDispatcher(“/pagina.html");
– Una vez tenemos el recurso accesible podemos:

• Hacer que el recurso sea el encargado de dar la
respuesta a la petición. Usamos el método “forward”
por lo que no podemos responder nosotros.
• Hacer una respuesta conjunta a la petición entre el
recurso y nuestro servlet usando el método “include”
• En otra ocasiones puede que se quiera
compartir recursos entre distintos servlets.
• Hacer uso de los atributos del
“ServletContext”.
• Útil para servlets del mismo servidor y sobre
todo para servlets de la misma aplicación.
• CONVENCIÓN PARA NOMBRES DE
ATRIBUTOS: Se suele usar la misma nomenclatura
usada para los paquetes para evitar conflictos.
– Añadir un atributo: Se usa el método “setAttribute”
de “ServletContext”. Esto se suele hacer en la
inicialización del servlet. El control de que varios servlets
manejen un mismo atributo es responsabilidad del
desarrollador.
– Recoger un atributo: Se usa el método
“getAttribute” de “ServletContext”. Hay que
convertir el objeto que devuelve al tipo requerido.
– Eliminar un atributo: Se puede eliminar un

atributo del contexto usando el método
“removeAttribute” de “ServletContext”.
Reenviando Respuestas
• Es posible delegar el procesamiento de un servlet a
otro mediante la clase
javax.servlet.RequestDispatcher
• Define dos métodos:
– include  sirve para incluir contenido de otro recurso
– forward  para enviar una petición de un servlet a otro
• Difiere de HttpServetResponse.sendRedirect(), que
redirige la petición con la ayuda del navegador
• Para obtener un objeto RequestDispatcher:
– A partir del método getRequestDispatcher o
getNamedDispatcher de
javax.servlet.ServletContext  path recibido
relativo al directorio raíz del servidor o nombre del recurso
– El método getRequestDispatcher de
javax.servlet.ServletRequest  recibe un
path como parámetro relativo a la petición actual HTTP
// Revisar: examples\servlets\ej10_include_servlet
RequestDispatcher rd =
request.getRequestDispatcher("/servlet/SecondServl
et?name=diego");
rd.include(request, response);
// Revisar: examples\servlets\ej11_forward_servlet
RequestDispatcher rd =
request.getRequestDispatcher("SecondServlet");
rd.forward(request, response);
Gestión de Sesiones
• HTTP no tiene estado
• Necesario utilizar trucos para permitirlo:
– Reescritura de urls
– Campos hidden <input type=“hidden”
name=“saludo” value=“hola”>
– Cookies
– HttpSession
Servlets: Respondiendo: Cookies
• Pequeños trozos de información textual que el
servidor puede enviar al cliente y que éste no
modifica y reenvía al servidor cuando vuelve a visitar
el mismo sitio.
– Identificar a un usuario concreto.
– Para sitios con baja necesidad de seguridad, poder evitar el
login y password.
– Personalizar las webs recordando cada peculiaridad de
cliente.
– Publicidad enfocada (personalizada) dado que se puede
almacenar información sobre las preferencias del usuario
mientras navega, busca información etc.
• Las cookies no son un grave problema de seguridad.
• Los navegadores sólo permiten 20 cookies por sitio
web y 300 en total.
• Limitadas a 4kb.
• Pueden ser un problema de privacidad. Puede que
algunos usuarios desactiven las cookies por diversas
razones por lo que no se recomienda depender
completamente del uso de ellas.
• Para utilizar cookies lo único que hay que hacer es:

• 1) Crear una cookie: “new Cookie(String
name, String value)”
El nombre no puede contener ni espacios ni: [ ]
( ) = , " / ? @ : ;
• 2) Especificar algún atributo a la cookies mediante
alguno de sus métodos:
– getComment/setComment: Comentarios asociados a
la cookie.
– getDomain/setDomain: Indicar el dominio

al que se aplica la cookie. Por defecto la cookie
se devuelve a la misma dirección que la envió,
pero así podemos indicar que se reenvíe a otros
servidores en el mismo dominio. El dominio debe
empezar por un ‘.’
– getMaxAge/setMaxAge: Indicar el tiempo
que debe pasar en segundos hasta que la cookie
expire. Si no se indica la cookie dura una sesión.
– getName/setName: Indicar el nombre de la
cookie.
– getPath/setPath: Indica a que rutas responde
la cookie. Si no se indica nada, la cookie se envía
para cualquier página en el mismo path actual. Se
podría usar para usos generales como
someCookie.setPath("/"). Hay que incluir
al menos el directorio actual.
– getSecure/setSecure: Sólo vale para
sesiones seguras (e.i. SSL).
Servlet: Respondiendo: Cookies
– getValue/setValue: Indicar el valor de la
cookie.
– getVersion/setVersion: Indicar con que
version del protocolo funciona esta cookie.
• 3) Añadir la cookie a la respuesta:
“response.addCookie(Cookie)”
• Para acceder a las cookies que el cliente

reenvía cada vez que accede al recurso se usa
el método “getCookies” de
“HttpServletRequest” que devuelve un
array de cookies.
• Con los métodos “getName” y “getValue”
de “Cookie” se accede a la información de la
cookie.
Servlets: Seguimiento de sesión
• El protocolo HTTP no posee la capacidad de almacenar
estados.
• Se complican mucho las tareas de guardar las acciones (e.i.
Compras) de un usuario.
• 3 posibles soluciones:
– Cookies.
– Añadir información en la URL
– Usar campos ocultos de formularios (HIDDEN)
• Revisar:
examples\servlets\ej12_cookie_servlet
• Los servlets proporcionan una solución
técnica: La API HttpSession.
• Una interfaz de alto nivel construida sobre los
cookies y la reescritura de las urls (pero
transparente para el desarrollador).
• Permite almacenar objetos.
• Pasos para trabajar con sesiones:
– BUSCAR EL OBJETO HttpSession
ASOCIADO A UNA PETICIÓN: Se usa el
método “getSession” de
“HttpServletRequest” que devuelve null
si no hay una sesión asociada. Entonces podríamos
crear una pero al ser una tarea sumamente común,
se pasa true y él mismo se encarga de crear una.
– BUSCAR INFORMACION ASOCIADA A LA
SESION: Usar los métodos “getValue” (o
“getAttribute” para versiones del API Servlet 2.2+)
que devuelve un Object o null. Para asignar un valor
dentro de una sesión se usa el método “putValue” (o
“setAttribute” para versiones del API Servlet 2.2+).
Para conocer los nombres de los valores están los métodos
“getValueNames” (o “getAttributeNames para
versiones del API Servlet 2.2+) que devuelve un
Enumeration.
– Existen otros métodos que aportan información sobre la
sesión.
getId. Este método devuelve un identificador único generado para cada sesión.
Algunas veces es usado como el nombre clave cuando hay un sólo valor asociado
con una sesión, o cuando se uso la información de logging en sesiones anteriores.
isNew. Esto devuelve true si el cliente (navegador) nunca ha visto la sesión,
normalmente porque acaba de ser creada en vez de empezar una referencia a una
petición de cliente entrante. Devuelve false para sesión preexistentes.
getCreationTime. Devuelve la hora, en milisegundos desde 1970, en la que se
creo la sesión. Para obtener un valor útil para impresión, pasamos el valor al
constructor de Date o al método setTimeInMillis de GregorianCalendar.
getLastAccessedTime. Esto devuelve la hora, en milisegundos desde 1970, en
que la sesión fue enviada por última vez al cliente.
getMaxInactiveInterval. Devuelve la cantidad de tiempo, en segundos, que la
sesión debería seguir sin accesos antes de ser invalidada automáticamente. Un valor
negativo indica que la sesión nunca se debe desactivar.
– AÑADIR INFORMACION A UNA SESION: Los métodos
“putValue” y “setAttribute” eliminan (machacan) el valor
anterior del atributo por lo que para añadir información hay que
recuperar el valor primero y después de modificarlo, volver a pasarlo a
la sesión.
– INVALIDAR UNA SESION: Automáticamente el servidor web
invalida tras un periodo de tiempo (30’) sin peticiones o manualmente
usando el método “invalidate”.
• Revisar:
examples\servlets\ej13_session_servlet
JDBC de Javasoft: arquitectura I
A p lic a c ió n A p lic a c ió n
Java Java
API JD BC
G e s t o r d e D r iv e r s
D r iv e r A P I
P r o to c o lo
A P I N a tiv o D r iv e r d e R e d
J D B C -O D B C N a tiv o
P a rte e n J a v a e n J a v a P u ro
T ip o 1 D r iv e r e n J a v a
T ip o 2 T ip o 3
T ip o 4
P r o to c o lo
de R ed
G e s to r d e D r iv e r d e P r o p ie ta r io
D r iv e r O D B C S G B D N a t iv o
S e r v id o r
D r iv e r O D B C
D r iv e r d e
S G B D N a tiv o
P r o to c o lo P r o to c o lo P r o to c o lo P r o to c o lo
SG BD SG BD SG BD SG BD
N a tiv o N a tiv o N a tiv o N a t iv o
JDBC de Javasoft: arquitectura II
• Gestor de drivers es núcleo de arquitectura y
comunica aplicaciones Java con cuatro tipos
diferentes de drivers:
– Puente ODBC-JDBC más el driver ODBC
• Traduce JDBC en ODBC
• No adecuado si parte cliente es anónima
– Necesidad de registrar fuente ODBC en cada máquina
• Uso: aplicaciones de dos capas en red local
JDBC de Javasoft: arquitectura III
– API Nativo parte en Java:
• Traduce JDBC en protocolo específico de BD: Oracle JDBC/OCI
driver
• Requieren algo de código nativo en cada máquina cliente en forma
de un driver específico que se debe instalar
• Uso: servidores RMI, servlets
– Driver de Red en Java Puro:
• Utiliza protocolo comunicaciones publicado para la comunicación
con un servidor remoto
• Servidor se comunica con la BD utilizando ODBC o un driver
nativo
• Java puro: applets  se descarga lo mínimo
• No requiere código instalado en máquina cliente
JDBC de Javasoft: arquitectura IV
– Protocolo nativo en Java Puro:
• Implementan protocolo de BD de un suministrador
• Específicos para BD concreta
• No tienen necesidad de intermediarios
• Alto rendimiento
JDBC URLs
• URL: esquema de nombres para

localizar BD
• Sintaxis:
– jdbc:<subprotocolo>:<subnombre>
– jdbc:odbc:cliente
– jdbc:msql://www.deusto.es:1112/cat
alogo
– jdbc:mysql://localhost:3306/docman
JDBC API: java.sql.* I
• Carga de un driver
– Crea instancia de si mismo
– Se registra con el gestor
String myDriver =
“sun.jdbc.odbc.JdbcOdbcDriver”;
Class.forName(myDriver);
• Conexión a la BD:
String url = “jdbc:odbc:clientes”;
String user = “dba”;
String pass = “sql”;
Connection dbCon =
DriverManager.getConnection(url, user,
pass);
JDBC API: java.sql.* II
• Ejecución de sentencias SQL

Statement stmt = dbCon.createStatement();
• 3 posibilidades:
– executeQuery()  1 conjunto de resultados
ResultSet res = stmt.executeQuery(“select * from
compradores where prio=1”);
– executeUpdate()
• DML (insert, update, deletee)  nº filas afectadas
• DDL (create table)  0
int total = stmt.executeUpdate(“insert into
prioridad (cod-pri, descripcion) values (4,
‘crítica’)”);
– execute ()
• Cuando no se sabe que va a devolver  ResultSet o nº
JDBC API: java.sql.* III
• Otras posibilidades:
– PreparedStatement, se genera el plan de acceso la
primera vez que se solicita la ejecución
PreparedStatement ps =
dbCon.prepareStatement(“sqlString”);
– CallableStatement  procedimientos almacenados
– Acceso al esquema o metadatos
– Control transaccional superficial
• Defecto  automático (1 SQL  1 commit)
• Deshabilitar (N SQL  1 commit o rollback)
dbCon.setAutoCommit(false);
…
dbCon.commit();
Un ejemplo JDBC
import java.sql.*;
…
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
String url = "jdbc:odbc:CuentasBD";
con = DriverManager.getConnection(url, "", "");
stmt = con.createStatement();
Vector cuentas = new Vector();
String sql = "select * from CUENTAS order by
numeroCTA";
ResultSet rs = stmt.executeQuery(sql);
while (rs.next()) {
cuentas.add(new
CuentaBancaria(rs.getString("numeroCTA"),
rs.getDate("fechaExpiracion"),
rs.getFloat("saldo")));
}
stmt.close();
con.close();
SQL Inmerso (Embedded SQL – ESQL)
 ESTÁTICO
• El lenguaje de programación junto con el cual se utiliza
SQL se denomina lenguaje anfitrión
• Objetivo: insertar sentencias SQL en aplicaciones
codificadas en cualquier lenguaje:
– C, C++, COBOL, FORTRAN, Pascal, ADA y Java
– Identificadores especiales para cada lenguaje, se usan para
separar las instrucciones de SQL inmerso y el código del
lenguaje anfitrión:
• Java SQLJ:
– # sql {insert into Pedidos values(:p1
:p2};
• C PRO*C:
– EXEC SQL DECLARE stu_cursor CURSOR FOR
SELECT * FROM STUDENT ORDER BY NAME;
• Precompilador genera código en lenguaje apropiado a
partir de las sentencias SQL incrustadas
SQL Embebido (Embedded SQL –
ESQL) (cont)
• Ventajas:
– Verificación de sintaxis en tiempo de
compilación  mayor eficiciencia
• Desventajas:
– BD debe ser conocida y su esquema accesible
en tiempo de compilación
– Precompiladores no estándar y propietario
para cada BD
SQLJ vs. JDBC
String vName; int vSalary; String vJob;
Java.sql.Timestamp vDate;
... ESTÁTICO  SQLJ
#sql { SELECT Ename, Sal
INTO :vName, :vSalary
FROM Emp
WHERE Job = :vJob and HireDate = :vDate };
String vName; int vSalary; String vJob;

Java.sql.Timestamp vDate;
... DINÁMICO  JDBC
PreparedStatement stmt =
connection.prepareStatement( "SELECT Ename, Sal " + "FROM Emp " +
"WHERE Job =? and HireDate = ?");
stmt.setString(1, vJob);
stmt.setTimestamp(2, vDate);
ResultSet rs = stmt.executeQuery();
rs.next();
vName = rs.getString(1); vSalary = rs.getInt(2);
rs.close();
Servlet con JDBC
// examples\servlets\ej14-db_servlet
public class RegistrationServlet extends HttpServlet {
private String firstName = "";

private String lastName = "";
private String userName = "";
private String password = "";
public void init() {

try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
System.out.println("JDBC driver loaded");
}
catch (ClassNotFoundException e) {
System.out.println(e.toString());
}
}
Servlet con JDBC
public void doPost(HttpServletRequest request,
sendPageHeader(response);
firstName = request.getParameter("firstName");
lastName = request.getParameter("lastName");
userName = request.getParameter("userName");
password = request.getParameter("password");
boolean error = false;

String message = null;
try {
Connection con = DriverManager.getConnection("jdbc:odbc:UsersDB");
System.out.println("got connection: " + password);
Statement s = con.createStatement();
String sql = "SELECT UserName FROM Users" +

" WHERE userName='" + StringUtil.fixSqlFieldValue(userName) + "'";
ResultSet rs = s.executeQuery(sql);
System.out.println("Ejecutando select: ");
if (rs.next()) {
rs.close();
message = "The user name <B>" + StringUtil.encodeHtmlTag(userName) +
"</B> has been taken. Please select another name.";
System.out.println(message);
error = true;
}
// ...
}
Servlet Filters
• Un filtro te da acceso a los objetos

HttpServletRequest y HttpServletResponse
antes y después, respectivamente, de que lleguen a un
recurso web.
• Los filtros se declaran en el web.xml con el elemento
xml <filter> y su uso se indica mediante <filter-
mapping>
– Se puede asociar un filtro a un patrón de url
– Además los filtros se pueden encadenar
• Definidos por los interfaces: Filter, FilterConfig
y FilterChain
• Revisar:
examples\servlets\ej15_filter_servlet
Ejemplo Filter
// compile: javac -classpath %TOMCAT_HOME%\common\lib\servlet-
api.jar;. UpperCaseFilter.java
import java.io.*;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import java.util.Enumeration;
public class UpperCaseFilter implements Filter {

private FilterConfig filterConfig = null;

System.out.println("Filter destroyed");
this.filterConfig = null;
}
Ejemplo Filter
public void doFilter(ServletRequest request, ServletResponse
response,
FilterChain chain)
throws IOException, ServletException {
System.out.println("Filter");
Enumeration enum = request.getAttributeNames();
while (enum.hasMoreElements()) {
String attributeName = (String) enum.nextElement();
String attributeValue = (String)
request.getAttribute(attributeName);
request.setAttribute(attributeName,
attributeValue.toUpperCase());
}
chain.doFilter(request, response);
}
public void init(FilterConfig filterConfig) throws
ServletException {
System.out.println("Filter initialized");
this.filterConfig = filterConfig;
}
}
Web.xml
<web-app>
<filter>
<filter-name>
Trim Filter
</filter-name>
<filter-class>
TrimFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>
Trim Filter
</filter-name>
<servlet-name>
DoublyFilteredServlet
</servlet-name>
</filter-mapping>
<servlet>
<servlet-name>
</servlet-name>
<servlet-class>
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>DoublyFilteredServlet</servlet-name>
<url-pattern>/servlet/DoublyFilteredServlet</url-pattern>
</servlet-mapping>
</web-app>
Servlet
• Son flexibles y muy potentes
• Sin embargo, es muy lioso mezclar código de
marcado y código Java
– A menudo hay más código de marcado que código
Java
• SOLUCIÓN  JSP

Servlets para Fin de Sesion Hoy

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servlets para Fin de Sesion Hoy

Uploaded by

Copyright:

Available Formats

Introducción

• Necesidad de mecanismos para desarrollar

HTTP Request Servlet Container Servlet

1. Crear una estructura de directorios bajo

• El directorio %TOMCAT_HOME%/webapps es dónde cuelgas tus

• La jerarquía de clases java es...

• Únicamente hay que hacer polimorfismo de

• Posible solución: Contador

• Falta indicar la terminación.

public class ConfigDemoServlet implements Servlet {

public void init(ServletConfig config) throws ServletException {

public void service(ServletRequest request, ServletResponse response)

ServletContext servletContext = servletConfig.getServletContext();

System.out.println("Major version : " + servletContext.getMajorVersion());

PrintWriter out = response.getWriter();

public class SimpleServlet extends GenericServlet {

public void service(ServletRequest request, ServletResponse response)

PrintWriter out = response.getWriter();

• GET: Paso de parámetros en la propia URL de acceso al

public class DoGetDoPostServlet extends HttpServlet {

• Si el parametro tiene mas de un valor se usa

public class PruebaServlet extends HttpServlet {

• Los métodos para acceder a estas cabeceras son:

public class PruebaServlet extends HttpServlet {

• La línea de estado consta de:

Cuerpo de la respuesta ...

• Existen 2 métodos para cabeceras relacionadas

• Se puede consultar si una cabecera ya ha sido

• "HttpServletResponse" también suministra

– Seguidamente debemos acceder al recurso:

– Una vez tenemos el recurso accesible podemos:

– Eliminar un atributo: Se puede eliminar un

• Para utilizar cookies lo único que hay que hacer es:

– getDomain/setDomain: Indicar el dominio

• Para acceder a las cookies que el cliente

• URL: esquema de nombres para

• Ejecución de sentencias SQL

String vName; int vSalary; String vJob;

private String firstName = "";

public void init() {

boolean error = false;

String sql = "SELECT UserName FROM Users" +

• Un filtro te da acceso a los objetos

public class UpperCaseFilter implements Filter {

public void destroy() {

You might also like