Desarrollo web con JSP

CAPITULO 1: Introduccin
Diferenciar entre contenido web esttico y dinmico.
Ver las diferentes formas de crear contenido web dinmico.
Diferenciar entre la programacin del lado del cliente (JavaScript) y
la programacin del lado del servidor (JSP).

Notas
Al crear un nuevo proyecto web en NetBeans, siempre debemos de
ejecutar luego de haberlo creado para verificar que ejecute el
HolaMundo y descartar que existan problemas con NetBeans o el
servidor de aplicaciones.
Las pginas de servidor Java o JSP es una tecnologa que sirve para
crear sitios web dinmicos.
Los JSP se construyen sobre los servlets que tambin se crearon
mucho antes para mostrar contenido dinmico. Normalmente los
JSP y los servlets se usan juntos, es decir se complementan entre
ellos.
Con HTML simple no podramos generar contenido dinmico, por
eso aqu entra en juego tecnologas como ASP.NET y JSP.
Tomcat:
Llamado tambin contenedor de servlet o servidor de aplicaciones.
Es el responsable de recibir las peticiones web y pasarlas a las
aplicaciones web en Java.
El puerto 8080 es el nmero de puerto que el servidor web
escucha. Una pc puede tener varios programas de servidor
escuchando a los clientes como navegadores web para conectar
con ellos; cada uno debe tener un nmero de puerto diferente.
Normalmente los servidores web usan el puerto 80.
Protocolo:

En el sentido de interconexin, un protocolo define como un

dispositivo o programa se comunica con otro. HTTP es un protocolo
de red que define como se comunica un cliente web y un servidor
web.
Por lo tanto la peticin que el cliente enva al servidor se conoce
como peticin HTTP y la respuesta enviada por el servidor al cliente
se llama respuesta HTTP.
Interfaz Comn de Pasarela (CGI)
Es uno de los primeros mecanismos a travs del cual los usuarios
podan realmente ejecutar programas en servidores web y no
simplemente pedir paginas HTML. Es decir bajo este modelo:
1 El navegador web enva una peticin al servidor web
2 Este servidor web est configurado para que sepa que el recurso
solicitado corresponde a un programa externo.
3 En ese momento el servidor web ejecuta el programa externo
pasndole la peticin HTTP que recibi del navegador.
4 El programa externo lleva a cabo su trabajo.
5 El servidor web enva la respuesta del programa de nuevo al
navegador como si se tratara de una respuesta HTTP.
Pero a medida que la red creci y la demanda de trfico situado en sitios
web aumento, CGI no era lo suficientemente eficiente para continuar ya
que con CGI cada vez que se recibe una peticin, el servidor web tiene
que empezar a ejecutar una nueva copia del programa externo siendo
demasiado lento teniendo en cuenta que cientos o miles hacen las
solicitudes a la vez. Imaginar que tendramos que ejecutar y lanzar una
copia diferente para cada uno de esas peticiones para cada uno de los
miles de usuarios solicitantes.
Alternativas a CGI
Soluciones alternativas a CGI se han construido sobre Apache, un
popular servidor web de cdigo abierto. Bajo el contexto de apache, los
mdulos se cargan en memoria cuando apache se pone en marcha y el
mismo apache pasa las peticiones HTTP adecuadas a aquellos mdulos
residentes en la memoria y transfiere las respuestas HTTP otra vez al
navegador significando todo esto mayor rapidez.
Por otro lado Java permita que sus desarrolladores ejecutaran sus
aplicaciones correctamente en el navegador web. Muchos sabidos del
tema en ese entonces pronosticaron que estos llamados applets de
Java (applet hace referencia a una mini aplicacin que se ejecutaba

dentro del navegador) se pondran de moda pero no fue as ya que

fueron superados en popularidad por tecnologas como Macromedia
Flash. Ms informacin en java.sun.com/applets.
Pero estos arquitectos de java no se daran por vencidos y tenan otro as
en la manga: los servlets de java. Los servlets por ellos mismos, no
son aplicaciones autnomas; se cargan en la memoria mediante un
contenedor de servlet. Este contenedor de servlet funciona entonces
como un servidor web, recibiendo peticiones HTTP de los navegadores
web y pasndolos a los servlets.
Por lo tanto gracias a la simplicidad del lenguaje Java, su naturaleza
independiente de la plataforma, el cdigo abierto convirtieron a los
servlets en una solucin inmensamente popular para crear contenido
web dinmico.
Paginas de Servidor Java
Para hacer la creacin de contenido web dinmico todava ms fcil,
java introdujo las Pginas de Servidor Java. Adems significo y significa
una alternativa a los desarrolladores en ASP.

Javascript
Ahora hablaremos un poco de JavaScript:
Es una tecnologa que permite a las pginas web tener alguna
funcionalidad de programacin en el navegador.
Trabaja junto con la pagina HTML y puede manipularla.
Inicialmente se llam Livescript pero fue cambiada por Netscape a
Javascript.
Fue desarrollado casi al mismo tiempo que se dio a conocer java.
Microsoft como siempre nunca se queda atrs y saco su propio
lenguaje script: JScript y luego de un tiempo se desarrollo un
estndar neutro llamado ECMAScript.
CSS
Hay 3 formar de trabajar con estilos, en lnea, interno y externo. Lo
mejor es usar de forma externa ya que de esta manera separamos
diseo y funcionalidad. Todo el diseo lo haremos en una hoja
especialmente para el diseo aparte y en nuestro JSP tan solo
importaremos o haremos referencia.
En nuestro archivo CSS, si colocamos body y le asignamos
propiedades, entonces toda nuestra pgina JSP que contenga body
tomar esos valores. De la misma manera si coloco h1 y le asigno

propiedades, entonces todos los h1 que tenga mi JSP tomarn esos

valores.
De otra manera podemos asignar nombres especiales que
empezarn con # y de esta manera tendremos que llamarlo de
manera especial usando propiedad id dentro de div. Es decir todo lo
que empiece con numeral no afectara a nada mientras no lo
llamemos.

Nota:
1. Si en nuestro JSP tenemos algo como:
<%= new java.util.Date() %>
Nuestro contenedor de servlet o servidor de aplicaciones tratara de
ejecutar cualquier cdigo que este dentro de esas etiquetas las cuales
se denominan etiquetas de expresin scriptlet.
Scriptlet hace referencia a cualquier cdigo dentro de <% %> y su
uso excesivo en genera una aplicacin confusa si es que nuestra
aplicacin creci en el tiempo y quisiramos darle mantenimiento.

2. Los mdulos que forman una aplicacin empresarial pueden ser de

tres tipos:
a. Archivos JAR (Java Archive): Los archivos JAR permiten agrupar
distintos archivos .java en uno solo. Es el empleado para
empaquetar componentes EJBs.
b. Archivos WAR (Web Application Archive): Los archivos WAR
permiten empaquetar en una sola unidad aplicaciones web
completas (servlets, pginas JSPs, contenido esttico como
imgenes y otros recursos Web).
c. Archivos EAR (Enterprise Application Archive): Los archivos EAR
son archivos desplegables en servidores de aplicaciones JEE.
Contienen archivos WAR y EJBs empaquetos en ficheros JAR.

CAPITLO 2: Obtencin de datos del navegador

Veremos algunos elementos HTML como <form> en el cual se
puede incluir algunos controles como radio botones, cajas de texto,
casillas de verificacin, botones de envo, etc.
Veremos cmo se trabaja con elementos <input>, <textarea>,
<select>, <option> y sus respectivos atributos.
Veremos que los datos del formulario pueden pasarse del cliente al
servidor en pares nombre/valor usando mtodos como get o post.
Veremos cmo los datos del formulario enviados por los usuarios en
el navegador, pueden ser recuperados desde el objeto request a
travs de sus mtodos getParameter() y getParameterValues().

2.1 Recuperacin de los datos del cliente usando

formularios HTML
El elemento <form>
Atributo method:
En method podemos indicar get o post. Get tiene ventajas frente a
post, por ejemplo las paginas que se cargan usando post, no
pueden ser agregadas correctamente a la lista de favoritos
mientras que las cargadas con get resultan fciles de agregar.
Post es una manera ms segura que hacerlo usando get.

Atributo target:
Puede usarse para identificar un cuadro o ventana dentro del
navegador al que debera de enviarse la pgina HTML resultante.

2.2

Uso de controles HTML

El elemento <input>
Atributo type:
Este atributo puede tomar valores como:
Text: se usa para presentar campos de texto

Password

Hidden: para definir controles ocultos

Checkbox

Radio

Reset: se usa para presentar un botn de control usado para

restablecer los contenidos del formulario a sus valores
originales por defecto.
Submit

Image: se usa para presentar un mapa de imgenes.

Button

file

Atributo checked:
Se usa solo si el atributo type del elemento input se defini como
radio o checkbox. Sirve para indicar por defecto que aparezca
seleccionada determinada opcin.
Atributo value:
Si se defini el atributo type como radio o checkbox, el
contenido en value define el valor que se enva al enviar el
formulario.
Pero si se defini el atributo type como text, el contenido de
value define el valor con el cual se pre rellenar la caja de
texto.
Finalmente si se defini el atributo type como button o submit,
el contenido de value define el texto que se mostrar en el
botn.

2.3

Procesamiento de peticiones

Los contenedores web J2EE brindan un conjunto de variables

implcitas que pueden usarse dentro de las paginas JSP sin una
declaracin explcita como por ejemplo instancindolos con new.
Una de estas variables es el objeto request que contiene datos
de las peticiones del cliente.
El tipo de dato de un objeto request se llama HttpServletRequest.
Debemos de tener especial cuidado al momento de usar un
control de tipo checkbox ya que al recuperar los textos con las
opciones seleccionadas podramos pensar que se hara usando
request.getParameter() cuando en realidad debe de usarse
request.getParameterValues()
ya
que
por
cada
opcin
seleccionada, se almacenar como un elemento de tipo string
dentro del arreglo que se declare para recibirlo. Ms informacin
en Sistema_Pizzas, ProcesarPedido.JSP.
Nota: tener en cuenta que getParameterValues() devuelve una
matriz de strings. Adems si todas las casillas de verificacin
tienen el mismo nombre eso implica que se tiene que recibir los
valores en un arreglo.

CAPITLO 3: Presentacin de Java Beans.

Veremos cmo y porque deberamos organizar nuestro cdigo.
Veremos cmo usar los componentes para organizar el
contenido.
Como crear y usar Java Beans.
Cmo hacer llamadas a los beans usando etiquetas beans.

3.1

Organizacin del cdigo

Como mencionamos, vamos a ver a continuacin como organizar

mejor nuestro cdigo en componentes. Una forma de hacer esto es
mover los datos y la funcionalidad presentes en los scriptlets a java
beans. Esto se hace necesario ya que a medida que nuestro

aplicativo crece, los scriptlets se harn ms largos y complicados,

haciendo a los JSP ms difciles de entender y mantener
Tener en cuenta que cuando diseos una aplicacin basada en JSP
debemos tener consideraciones importantes como:
Reutilizacin del cdigo: ya que esto permitir acelerar el
desarrollo de nuestra aplicacin y facilitar el
mantenimiento de la aplicacin.
3.2

Componentes

Entonces cuando diseos una aplicacin web, 2 objetivos

importantes son:
La reutilizacin del cdigo.
Agrupamiento del cdigo en capas.
Y una de las maneras de lograr estos objetivos es dividir el cdigo
en componentes (o mdulos de funcionalidad) ya que esta divisin
en componentes permite que una parte compleja de cdigo
compuesta por muchos tupos de funcionalidad sea dividida en
trozos (mdulos)
3.3 Introduccin a los Java Beans
Para usar realmente los componentes con pginas JSP se hace uso
de Java Beans o tambin llamados beans.
Por ejemplos podramos tener un bean que modelara una cuenta
bancaria. Este bean podra tener propiedades de nmero de cuenta
y de saldo.
Finalmente un bean no es ms q una clase que mantiene algunos
datos. Un java bean o bean yo lo conozco con el nombre de
entidad.
Propiedades
Las propiedades de un java bean se exponen pblicamente usando
mtodos getter y setter.
Etiquetas bean
Uno de los objetivos era eliminar el uso excesivo de scriptlets para
hacer nuestro cdigo ms sencillo de seguir. Si implementamos
nuestros beans estableciendo sus propiedades get y set, en
nuestros JSP a travs de scriptlets podemos instanciar estos beans
y luego hacer uso de sus mtodos get y set.

Pero de esa manera estaremos introduciendo mas scriptlets

conteniendo llamadas con cdigo Java a dichos mtodos. Por este
motivo aparecen lo que se denominan etiquetas beans que nos
permitir eliminar la necesidad de los scriptlets y de llamar a los
mtodos del bean usando cdigo Java. Es decir java usa un mtodo
de uso de java beans que se basa en el concepto de etiquetas.
Estas etiquetas permiten al diseador usar JavaBeans sin saber
nada de Java.
Existen 3 etiquetas estipuladas para sostener el uso de JavaBeans
JSPs:
a. Etiqueta <jsp:useBean>: localiza y hace una llamada a un
JavaBean.
<jsp:useBean id=cliente class=Cliente/>
Si mostrara error es porque posiblemente tengamos que colocar
la ruta completa antes de clsCliente.
(Ver a que hace referencia el atributo id, revisar el libro. Ver si
se especifica el uso de un atributo scope)
Otra forma de cierres es:
<jsp:useBean id=cliente class=Cliente>
</jsp:useBean>
b. Etiqueta <jsp:setProperty>: Establece el valor de un atributo
de un bean. Usa su mtodo setter.
<jsp:setProperty name=cliente property=apelidoPat
value=Rojas/>

c. Etiqueta <jsp:getProperty>: obtiene el valor de una

propiedad usando el mtodo getter y devuelve el valor de la
propiedad a la pgina JSP que lo demanda.
<jsp:getProperty name=cliente property=apellidoPat/>

CAPITLO 4: Introduccin a la biblioteca de

etiquetas.
Explicaremos el uso de bibliotecas de etiquetas mas no
programaremos nuestras propias. Lo haremos en un capitulo
posterior.
Analizaremos los componentes de una biblioteca de

4.1

La necesidad de las bibliotecas de etiquetas

Como se indico anteriormente, los java beans permiten separar la

aplicacin en niveles y usar componentes para brindar reutilizacin.
Sin embargo a menudo necesitaremos tomar decisiones en una
pgina JSP, quizs basadas en la peticin hecha por el cliente. Las
etiquetas beans no tienen este tipo de funcionalidad.
Adems las etiquetas beans no pueden tener ningn control y
tampoco pueden interactuar con la pgina JSP. Por ejemplo no
tienen acceso al objeto request y response lo que las bibliotecas
personalizadas si lo pueden hacer.
En este captulo mostraremos como usar una de las muchas
etiquetas a medida que ya estn escritas y disponibles. (Tener en
cuenta que crearemos nuestras propias biblioteca de etiquetas
recin en un capitulo posterior.)
4.2

Componentes

a. Manipuladores de etiquetas
Tipo de clases especiales que contienen la funcionalidad de la
etiqueta.
b. Descriptor de etiquetas
Es un documento XML que contiene informacin sobre una o
ms etiquetas personalizadas. Es decir este XML describe las
etiquetas personalizadas y las relaciona con sus de
manipuladores de etiquetas.
La norma es que un archivo TLD se denomina como la clase a la
que se refiere y debe ser almacenado en el directorio WEB-INF.
(Verificar con el libro)
c. La directriz taglib

Para usar las etiquetas de una biblioteca de etiquetas

personalizadas en las JSP, se aade en la parte superior lo
siguiente:
<%@taglib uri =
http://jakarta.apache.org/taglibs/request1.0 prefix =
req %>

Se necesita dicha directriz para cada biblioteca de etiquetas que

necesitemos usar.
El valor del atributo uri normalmente consta de una URL y no
es que se intente acceder a esa URL, solo existe para
identificar la biblioteca de etiquetas.
El atributo prefix se usa para identificar una etiqueta en un JSP
como parte de una biblioteca de etiquetas en particular. Por lo
tanto no hay ningn problema si tenemos 2 etiquetas con el
mismo nombre siempre y cuando procedan de diferentes
fuentes.
Funcionamiento y como es que se relacionan
Siempre que un motor JSP encuentra una extensin de etiquetas en
un JSP, mira el valor del atributo uri en la parte superior (directriz
taglib) y despus analiza sintcticamente el TLD para encontrar la
clase de manipulacin de etiquetas requeridas.
4.3

Uso de una biblioteca de etiquetas

Existen etiquetas personalizadas ya creadas por el proyecto Jakarta

como por ejemplo la biblioteca de etiquetas request.
Lo que debera seguir no lo veo tan importante para el uso.
Revisar que en el proyecto que implemente con JSTL del ing.
Llerena este lo que se indica en la pag. 168 sobre web XML.

CAPITLO 5: Seguir la pista a los usuarios.

Se ha desarrollado 3 mecanismos para permitir el seguimiento del
cliente:
Cookies
Reescritura URL
Campos de formulario ocultos
Uso de sesiones en paginas JSP
Debemos de tomar en cuenta que existe una sesin para cada
aplicacin web en el servidor. Esto significa que aunque las JSP en una
carpeta X o en sus subcarpetas puedan compartir datos de una sesin
entre ellas, no puedan compartirlos con JSP que se encuentren en la
carpeta Y. (Verificar yo mismo)
Me quede en la pag. 321 a documentar El obj Session en detalle

CAPITLO 6: Servlets y JSP

6.1 Introduccin
Gran parte de las prestaciones de la tecnologa JSP derivan de los
servlets Java, inclusive antes de ejecutar una pgina JSP, se
compila en un servlet. El proceso es el siguiente:
1 El programador disea una pgina JSP usando HTML, etiquetas
JSP y JavaBeans. En seguida se implementan en un contenedor
web el cual se queda esperando peticiones del cliente.
2 El cliente solicita una peticin al servidor mediante una URL.
3 Cuando el contenedor web recibe la primera solicitud para una
determinada pgina JSP, el contenedor genera un proceso en
el cual hace que la pgina se transforme en la clase java
equivalente a las instrucciones JSP. El contenedor se encarga
de crear este objeto que realmente es un servlet.
Pero si anteriormente se ha efectuado una peticin de carga
del mismo servlet, tan solo se le pasan los parmetros al
servlet y este ejecuta un hilo dentro del proceso generado
durante la primera peticin.
4 El contenedor enva la informacin de la solicitud al servlet y
este la procesa. Luego construye la respuesta y la transmite al
contenedor.
5 El contenedor recibe la respuesta y la enva hasta el cliente.
6 Cuando el motor de los servlets se cae por cualquier causa, se
llama al mtodo destroy() del servlet que es el encargado de
destruirlo, es decir de destruir el proceso creado por el motor
de Servlets, dentro de este mtodo incluiremos el cierre de las
conexiones, el cierre de ficheros abiertos, etc.

Esto es en resumen el ciclo de vida de un servlet. Como vemos el

contenedor es el responsable de cargar, ejecutar y administrar el
servlet.
Una gran ventaja del uso de servlets en una aplicacin web es que
permite separar la lgica del negocio con la lgica de la
presentacin (implementado en JSPs). Es decir en el servlet puedo
introducir cdigo Java como por ejemplo conexin a una fuente de
datos en caso que el JSP lo requiera.
Dentro de MVC, el servlet vendra a ser el controlador ya que acta
en funcin de la solicitud del cliente y coordina o delega en otros
servlets, archivos de recursos, bases de datos. Este controlador es
el que brinda las entradas para el modelo
En conclusin:
La combinacin de servlets con JSP permite crear contenido web
dinmico mezclando de forma ordenada lgica de presentacin en
los JSP y lgica de negocio o datos en los servlets. Estos servlets se
gestionan por medio de un servidor o contenedor web como
Tomcat.

6.2

Caractersticas

Por ser clases totalmente Java, los independizan de la

plataforma.
Descargan el servidor web en gran medida ya que solo en la
primera peticin hecha por el cliente, el servidor web crea un
proceso para el servlet y para peticiones posteriores este
servidor web tan solo crea hilos de ejecucin de este proceso.
Es ms rpido que CGI ya que los servlets estn pre compilados
y adems a diferencia del CGI, los servlets no generan procesos
independientes en el servidor web cada vez que solicita un URL.
Son ms seguro por usar el API de seguridad de Java.
Permite el control de excepciones en las cuales se le puede dar
tratamiento a los errores que pudieran ocurrir, de una forma
especial y bien sencilla.

6.3 Arquitectura de un servlet

La versin del API Servlet es la 2.5 incluida en la especificacin JSR
154.

La ltima versin para Java EE 6 es la API Serlvet 3.0 dentro de la

especificacin JSR 315.
Todo servlet implementa la interfaz Servlet. Esta interfaz define
una serie de mtodos que permiten inicializar, procesar peticiones
y destruir un servlet.
Todos
los
servlets
deben
implementar
la
interfaz
javax.servlet.Servlet, que declara mtodos para administrar
el servlet y la comunicacin con el cliente.
La clase encargada de implementar esta interfaz es la clase
abstracta GenericServlet que es la encargada para desarrollar
nuestros servlets.
En esta clase GenericServlet se define un mtodo llamado
service():
Este mtodo es el encargado de procesar las peticiones de los
clientes y que se invoca para cada una de las solicitudes que el
contenedor pasa al servlet.
Para la generacin de servlets que se basan en HTTP,
afortunadamente
contamos
con
una
clase
javax.servlet.http.HttpServlet
(que
hereda
de
GenericServlet) que nos permite implementar la interfaz
mencionada anteriormente (javax.servlet.Servlet) y es por eso
los servlets que crearemos extienden la clase HttpServlet.
Cuando un servlet acepta una llamada de un cliente, recibe dos
objetos: uno que implementa javax.servlet.ServletRequest y
un
segundo
que
hace
lo
mismo
con
javax.servlet.ServletResponse. La clase ServletRequest
contiene la comunicacin entre el cliente y el servidor, mientras
que la clase ServletResponse incluye la comunicacin
que
devuelve el servlet al cliente.
Pero como se trata de servlets HTTP, se usa un objeto request que
implementa la interfaz javax.servlet.http.HttpServletRequest
y un objeto response que se encarga de la implementacin de la
interfaz
javax.servlet.http.HttpServletResponse.
Ambas
interfaces extienden ServletRequest y ServletResponse.
Nota:

Si deseamos crear un servlet que sea independiente del protocolo,

se debe extender la clase GenericServlet y si deseamos que sea
bajo el protocolo HTTP, debemos extender la clase HttpServlet.
En la clase HttpServlet hay una serie de mtodos que nos
permitirn desarrollar servlets orientados al protocolo HTTP. Por
ejemplo si deseamos tratar una peticin que se realice a travs de
un formulario HTML con el mtodo POST, tenemos el mtodo
doPost, por el contrario, si el mtodo de acceso es GET, tenemos
el mtodo doGet() dentro de la misma clase HttpServlet.

6.4

Mtodos de la clase Servlet

HttpServlet dispone de algunos mtodos de inters:

init() y destroy() que permiten administrar recursos
asignados al servlet durante toda su vida operativa.
getServletInfo(): mtodo que usa el servlet para conseguir
informacin sobre s mismo.
Lo primero que se ejecuta al crearse una clase que implemente la
interfaz Servlet es su mtodo init(). Este mtodo se ejecuta antes
de procesar cualquier solicitud.
Al mtodo init(ServletConfig) se le pasa como parmetro un
objeto del tipo ServletConfig, que es la interfaz que nos permite
acceder a los parmetros del servlet y al contexto sobre el que se
ejecuta (ServletContext).
La interfaz ServletConfig define los siguientes mtodos:
1. String getInitParameter(String name).
2. Enumeration getInitParameterNames().
3. ServletContext getServletContext().
4. String getServletName().

El mtodo principal de la interfaz Servlet es el mtodo service()

encargado de procesar las peticiones y respuestas.
Para realizar todo ese proceso se le pasan dos parmetros:
ServletRequest.
ServletResponse.
Con el uso de estas dos interfaces tenemos la capacidad de tratar
las peticiones y responder a las mismas. Lo que se suele realizar
con estos dos parmetros es obtener las corrientes de entrada y
salida hacia el cliente.

Resmen:
Como se dijo anteriormente, no se suele implementar la interfaz
Servlet sino que se suele heredar o extender de la clase
GenericServlet. Recin aqu esta clase implementa la interfaz
Servlet. En nuestro caso nos centraremos principalmente en la
clase HttpServlet que es una extensin de GenericServlet.
As como en la clase GenericServlet, en la clase HttpServlet existe
tambin un mtodo service() que tiene de nuevo dos parmetros
pero en este caso son HttpServletRequest y httpServletResponse
que nos brindaran la gestin de las peticiones y respuesta usando
el protocolo HTTP.
HttpServletRequest ser el encargado de encapsular los
datos que vienen del cliente conteniendo los datos de la
peticin.
HttpServletResponse ser el encargado de gestionar la
respuesta de la peticin del cliente.
Cuando llega una solicitud al contenedor, busca una instancia del
servlet correspondiente, Si no lo encuentra, carga uno e invoca el
mtodo doGet() o doPost() de acuerdo a como se enviara la
solicitud.

Peticin de informacin
En la interfaz ServletRequest podemos encontrar una serie de
mtodos que nos dan toda la informacin sobre la peticin del
cliente:
Int getContentLength()
String getContentType(): retorna una cadena que nos
informa del tipo de contenido MIME de los datos que enva el
navegador del cliente al servlet.
String getProtocol()
getRemotePort()

 getRemoteHost(): retorna direccin ip.

getRemoteAddr()
Los parmetros pasados en la peticin al servlet se obtienen
con los mtodos getParameterNames(),getParameterValues(),
getParameterMap() y getParameter(). Si desconocemos por
completo el nombre de los parmetros que se pasarn en la
peticin se deben usar los mtodos getParameterNames() y
getParameterValues(String nombre).
El primero retorna una enumeracin con los nombres pasados
en la peticin y el segundo retorna un array de cadenas con
los valores del nombre pasado como parmetro al mtodo.

Generacin de la respuesta

Dentro de la interfaz ServletResponse, existen una serie de

mtodos que nos permiten comunicarnos con el cliente:
getWriter() y getOutputStream() que nos permitirn
comunicarnos con el cliente usando un canal de salida.
Antes de ejecutar los mtodos del primer punto, se debe usar
el mtodo setContentType(String tipocontenido) en el
cual se debe especificar el tipo de contenido que ver el
cliente. Podemos usar un contenido del tipo text/html
mediante: setContentType(text/html).
setContentLength(int longitud)
Existen muchos otros mtodos que nos permiten tratar la peticin y
generar la respuesta. Tenemos tambin dentro de la clase
HttpServletResponse el mtodo sendRedirect(String url) que
permite redirigir una peticin a otra URL.
(Me qued en la pgina 379 del libro fundamentos JSP, por
empezar a resumir la parte del objeto Request)

6.5 Inicializacin de un Servlet

Los servlets se pueden configurar para que arranquen con una
serie de parmetros por defecto. Estos parmetros son ledos
por el servlet durante el proceso de carga del servlet dentro del
servidor web.
Estos parmetros pueden ser obtenidos usando los mtodos
getInitParameter(String
parametro)
y
getInitParameterNames()
definidos
en
la
interfaz
ServletContext.

6.6 La clase HttpServlet

Como hemos comentado anteriormente, un servlet define el
mtodo service() para el tratamiento de las peticiones por parte del

cliente. Sin embargo si trabajamos con servlets que se basan en el

protocolo HTTP, necesitamos diferenciar las peticiones que pueden
generar los usuarios.
Para ese caso usamos la clase HttpServlet que especifica unos
mtodos que nos permite diferenciar las peticiones de los clientes,
estos mtodos son:
doGet()
doPost()
doDelete()
doPut()
Entonces, si definimos estos mtodos ya no es necesario definir el
mtodo service() ya que esto implicara que las peticiones sean
tratadas por este mtodo y ya no por los mtodos listados.

Mtodos doGet(), doPost(), doDelete() y doPut()

El mtodo doGet(HttpServletRequest, HttpServletResponse)
es el encargado de gestionar las peticiones que provengan de:
1. Un enlace tipo <a></a>.
2. Mediante parmetros asociados a una URL del navegador.
3. Ejecutando el botn submit de un formulario cuyo mtodo es
GET.
El mtodo doPost(HttpServletRequest, HttpServletResponse)
es el invocado cuando se llama a un Servlet, pulsando el botn
submit de una formulario con el mtodo POST.
El mtodo doPut() y doDelete() son invocados desde el botn
submit casi no se usan.
Veamos un ejemplo de implementacin de un Servlet del tipo
HttpServlet que implementa el mtodo doGet():
public class MiPrimerServlet extends HttpServlet
{
protected void processRequest(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException
{
PrintWriter out = null;
String titulo = "Mi primer servlet";
response.setContentType("text/html;charset=UTF-8");
out = response.getWriter();
out.println("<HTML><HEAD><TITLE>");
out.println(titulo);
out.println("</TITLE></HEAD><BODY>");
out.println("<H1>"+titulo+"</H1>");
out.println("<p>Manual avanzado de Java EE 6.");

out.println("</BODY></HTML>");
out.close();
}

Funcionamiento:
Cuadro se solicite una peticin del tipo GET al servlet
MiPrimerServlet, este se cargar, si aun no lo est, en el contexto
del servidor web y estar disponible para procesar la peticin.
La funcin que tiene este pequeo servlet es crear una pgina
HTML que se le enviar al usuario mediante el canal de salida
obtenido
del
objeto
response,
que
es
del
tipo
HttpServletResponse, usando para ello el mtodo getWriter().
Antes de generar la pagina HTML, debemos especificar que el
contenido de sta es del tipo text-html mediante el mtodo
setContentType().
Por ltimo debemos de agregarlo al archivo web.xml

6.7

El objeto HttpSession

Mediante una sesin podemos mantener informacin entre

conexiones HTTP.
En las sesiones de usuario se guarda toda aquella informacin
que despus se necesite.
La forma de obtener una sesin de usuario se realiza mediante
el objeto HttpSession, que nos retorna la sesin mediante el
mtodo getSession(boolean) del objeto HttpServletRequest,
generado en alguno de los mtodos de servicio (por ejemplo
doGet() o doPost()). El parmetro boolean pasado al mtodo
getSession() nos permite establecer que si la sesin del
cliente no est creada la cree.
Una vez obtenido un objeto del tipo HttpSession, podemos
obtener los valores de la sesin usando el mtodo
getAttribute(String valor) y para establecer valores
usaremos el mtodo setAttribute(String nombre, Object
valor). El mtodo getAttribute() nos retorna un objeto del
tipo Object.
Podemos invalidar la sesin de un usuario usando el mtodo
invaldate(). Este mtodo nos ser til cuando ya nos nos
sirva la sesin del usuario y deseemos limpiar la memoria
asignada a la sesin por el servidor web, por ejemplo cuando el
usuario realice un logout.

6.8 Uso de las Cookis

Introduccin
Como se vio anteriormente, una sesin para un cliente es creada
en el servidor web en la primera peticin del navegador del cliente.
Esta sesin era destruida bien porque el cliente cerrase el
navegador o por el timeout o porque el servlet invalidara la sesin
(usando el mtodo invalidate()).
Sin embargo, hay circunstancias que requieren que el almacenaje
de informacin del usuario dure ms de una sesin. Por ejemplo
aquellos portales que permiten personalizar el aspecto de la pgina
para cada usuario. Si este usuario tendra que modificarla cada vez
que se pierda la sesin, al final se cansara y nunca ms volvera a
modificarla. Por tanto se necesita un mecanismo que nos permita
alargar los valores de una sesin y es aqu donde entran en accin
las cookies.

Definicin
Las cookies son pequeos archivos que se quedan residentes en
el disco duro del cliente y permiten insertar informacin que
posteriormente necesitemos.
Las cookies estn implementadas en la clase Cookie.

6.9

APENDICE 1: Errores en NetBeans

Al momento de ejecutar nuestro aplicativo web teniendo como
servidor a glassfish, es posible que tengamos estos errores.
Error 1:
Cuando trato de ejecutar un proyecto JSP y se muestra un mensaje de
error diciendo que hubo error al momento de iniciar el Glassfish
Abrir el archivo domain.xml hiendo a la pestaa de servicios del
NetBeans, seleccionar el servidor (en este caso Glassfish), clic
derecho y propiedades, copiar esa ubicacin y dirigirse al
explorador de Windows.
Entrar a la carpeta domains, config, clic en el archivo domain y
cambiar a los puertos al puerto 8080 o sino al puerto 8082 o
8090.
Puedo comprobar que puertos estn ocupados ingresando en la
consola de Windows el comando netstat a

Links de inters:
http://blog.andersonrubio.com/2012/05/cambiar-el-puertopara-glassfish.html

Cuando ejecuto el proyecto seguir apareciendo en la barra de

direcciones http://8080:localhost..., ese 8080 modificarlo y
colocar 8081 y actualizar la pgina.

Error 2:
El problema que se resolvi fue por un tema de permisos, si vuelve a
aparecer ese error, debo de comentar la lnea que hace la llamada a
todo el bloque con <!-- .... -->
Ejemplo:
Si trato de ejecutar saldr el enlace a la lnea del error, le doy clic
ah y agrego los comentarios de la siguiente manera:
<!-<webproject2:javac destdir="${build.classes.dir}"
gensrcdir="${build.generated.sources.dir}"/>-->

Error 3:
En caso deseo encender el servidor de aplicaciones y el puerto en el cual se
ejecuta est ocupado, puedo matar el proceso que est usando ese puerto
de la siguiente forma: