C. Configurar Aplicaciones Web con Servlets o JSP

Una aplicación web que utilice servlets o páginas JSP debe tener una estructura de ficheros y directorios determinada:

• En el directorio raíz de la aplicación se colocan las páginas HTML o JSP (podemos dividirlas también en directorios si queremos)
• Colgando del directorio inicial de la aplicación, se tiene un directorio WEB-INF, que contiene la información Web relevante para la aplicación. Esta información se divide en:
  • Fichero descriptor de despliegue de la aplicación: es el fichero descriptor de la aplicación web. Es un fichero XML (web.xml en Tomcat o Resin, por ejemplo) que contiene información genérica sobre la aplicación. Lo veremos con más detalle más adelante
  • Subdirectorio classes: en él irán todas las clases Java utilizadas en la aplicación (ficheros .class), es decir, clases externas a la API de Java que se utilicen en las páginas JSP, servlets, etc. Las clases deberán mantener la estructura de paquetes, es decir, si queremos colocar la clase paquete1.subpaquete1.MiClase dentro de classes, se quedará almacenada en el directorio classes/paquete1/subpaquete1/MiClase.
  • Subdirectorio lib: aquí colocaremos las clases Java que estén empaquetadas en ficheros JAR (es decir, colocaremos los ficheros JAR de nuestra aplicación Web, y las librerías ajenas a la API de JDK o de servlets y JSP que se necesiten)
  • El resto de elementos de la aplicación (imágenes, etc), podemos estructurarlos como nos convenga.
• El resto de elementos de la aplicación (imágenes, etc), podemos estructurarlos como nos convenga.

Notar que se separan los ficheros .class de los ficheros JAR, colocando los primeros en el directorio classes y los segundos en lib.

Esta estructura estará contenida dentro de algún directorio, que será el directorio correspondiente a la aplicación Web, y que podremos, si lo hacemos convenientemente, copiar en el servidor que nos convenga. Es decir, cualquier servidor Web soporta esta estructura en una aplicación Web, sólo tendremos que copiarla en el directorio adecuado de cada servidor.

C.1.1. Rutas relativas en la aplicación

Supongamos que tenemos alguna imagen o recurso al que queremos acceder desde otro, en nuestra aplicacion Web. Por ejemplo, supongamos que colgando del directorio raíz de la aplicación tenemos la imagen miImagen.jpg dentro de la carpeta imagenes (es decir, imagenes/miImagen.jpg).

Podemos acceder a esta imagen de varias formas, aunque a veces podemos tener problemas con alguna, porque luego el contenedor Web tome la ruta relativa al lugar desde donde queremos cargar la imagen (o recurso, en general). Este problema lo podemos tener accediendo a elementos desde servlets, sobre todo.

Una solución para evitar esto es acceder a todos los elementos de la aplicación a partir del nombre del directorio de la aplicación. Por ejemplo, si tenemos toda nuestra aplicación en el directorio miAplicacion, para acceder a la imagen desde una página HTML, pondríamos:

<img src="/miAplicacion/imagenes/miImagen.jpg">

Como hemos dicho anteriormente, el directorio WEB-INF de una aplicación web con servlets y/o páginas JSP, debe haber un fichero descriptor de despliegue (llamado web.xml en servidores como Tomcat, entre otros) que contenga la información relativa a la aplicación.

Es un fichero XML, que comienza con una cabecera XML que indica la versión y la codificación de caracteres, y un DOCTYPE que indica el tipo de documento, y la especificación de servlets que se sigue. La etiqueta raíz del documento XML es web-app. Así, un ejemplo de fichero podría ser:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC 
 "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" 
 "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>
        <!-- Resto de elementos -->
</web-app>

En este caso se utiliza la especificación 2.2 de servlets o anteriores (para utilizar versiones posteriores habría que cambiar la especificación en la línea de DOCTYPE). Algunos servidores permiten omitir la cabecera XML y el DOCTYPE, pero sí es una buena costumbre el ponerlas.

Dentro de la etiqueta raíz <web-app> podemos colocar otros elementos que ayuden a establecer la configuración de nuestra aplicación web. Dichos elementos deben seguir un orden: podemos omitir los que no se necesiten, pero los que pongamos deben tener una colocación adecuada en el documento. Veremos a continuación algunos de ellos, en el orden en que deben aparecer si aparecen (existen otras etiquetas que no veremos aquí, y que debéis consultar el orden en que ponerlas). En algunos elementos profundizaremos un poco más, por tratarse de elementos genéricos de una aplicación web (variables globales, etc). En otros (servlets, filtros, etc), simplemente se indicará qué elementos se tratan, pero su configuración se explicará en temas más específicos.

C.2.1. Orden en las etiquetas del fichero descriptor

C.2.1.1. Información general de la aplicación

Primero tenemos etiquetas con información general:

• <display-name>: nombre con que deben utilizar las aplicaciones gráficas para referenciar a la aplicación
• <description>: texto descriptivo de la aplicación

C.2.1.1.1. Variables globales

Podemos tener varias etiquetas:

• <context-param>: para declarar las variables globales a toda la aplicación web, y sus valores. Dentro tiene dos subetiquetas:
  • <param-name>: nombre de la variable o parámetro
  • <param-value>: valor de la variable o parámetro

Un ejemplo:

<context-param>
	<param-name>param1</param-name>
	<param-value>valor1</param-value>
</context-param>

Estos parámetros pueden leerse desde servlets con el método getInitParameter() del objeto ServletContext.

C.2.1.2. Filtros

Para el tratamiento de filtros se tienen las etiquetas:

• <filter>: para asociar un nombre identificativo con la clase que implementa el filtro
• <filter-mapping>: para asociar un nombre identificativo de filtro con una URL o patrón de URL

Se pueden tener varias de estas etiquetas, cada una para un filtro.

C.2.1.3. Oyentes

Se tiene la etiqueta:

• <listener>: para definir una clase oyente que responde ante eventos en sesiones y contextos (al iniciar, al cerrar, al modificar).

C.2.1.4 Servlets

Para definir los servlets en nuestro fichero de configuración, se tienen las etiquetas:

• <servlet>: asocia un nombre identificativo con una clase Java que implementa un servlet
• <servlet-mapping>: asocia un nombre identificativo de servlet con una URL o patrón de URL.

Se pueden tener varias de estas etiquetas, cada una para un servlet.

C.2.1.5 Configuración de sesión

Se tiene la etiqueta:

• <session-config>: para indicar parámetros de configuración de las sesiones.

Por ejemplo, podemos indicar el tiempo (en minutos) que le damos a una sesión de usuario antes de que el servidor la finalice:

<session-config>
	<session-timeout>30</session-timeout>
</session-config>

C.2.1.6 Páginas de inicio

Se tiene la etiqueta:

• <welcome-file-list>: para indicar qué páginas debe buscar Tomcat como páginas de inicio en el caso de que en la URL se indique el directorio, pero no la página, como por ejemplo:

http://localhost:8080/unadireccion/dir/

Para ello, esta etiqueta tiene una o varias subetiquetas <welcome-file> para indicar cada una de las posibles páginas

Por ejemplo, podemos indicar que las páginas por defecto sean index.html o index.jsp con:

<welcome-file-list>
	<welcome-file>index.html</welcome-file>
	<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Las páginas se buscan en el orden en que se especifican en esta etiqueta.

C.2.1.7 Librerías de tags

Se tiene la etiqueta:

• taglib: para cargar una librería de tags para utilizar en páginas JSP. Podemos tener una o varias de estas etiquetas.

C.2.1.8 Seguridad

Para gestionar la seguridad en las aplicaciones Web se tienen las etiquetas:

• security-constraint: permite especificar qué URLs de la aplicación deben protegerse
• login-config: indica cómo debe autorizar el servidor a los usuarios que quieran acceder a las URLs protegidas (indicadas con security-constraint)
• security-role: da una lista de roles en los que se encuadrarán los usuarios que intenten acceder a recursos protegidos. 

Existen otras etiquetas internas, relacionadas con la seguridad, que no se encuentran detalladas aquí.

 

C.3. Ficheros WAR

Una forma alternativa de distribuir aplicaciones Web con Tomcat es empaquetar toda la aplicación (a partir de su directorio inicial) dentro de un fichero WAR (de forma parecida a como se hace con un TAR o un JAR), y distribuir dicho fichero. Podemos crear un fichero WAR de la misma forma que creamos un JAR, utilizando la herramienta JAR. 

Por ejemplo, si tenemos en el directorio C:/web/ejemplo los siguientes ficheros:

C:/web/ejemplo/
		index.html
		WEB-INF/
			web.xml
			classes/
				ClaseServlet.class

Para crear la aplicación WAR se siguen los pasos:

• Crear el WAR colocándonos en dicho directorio C:/web/ejemplo y escribiendo:

jar cMvf ejemplo.war *

Las opciones c, v y f son para crear el WAR como un JAR comprimido normal. La opción M (mayúscula) es para que no se añada el fichero Manifest. 

También es IMPORTANTE destacar que no debe haber subdirectorios desde la raíz de la aplicación, es decir, la estructura del fichero WAR debe ser:

index.html
WEB-INF/
	web.xml
	classes/
		ClaseServlet.class

sin ningún subdirectorio previo (ni ejemplo/ ni web/ejemplo/ ni nada por el estilo).

• Colocar el fichero WAR en el directorio de aplicaciones del servidor donde lo vayamos a ejecutar (dicho directorio es webapps en Tomcat, por ejemplo).
• Deberemos arrancar el servidor tras hacer esto. Al arrancarlo, vemos que se creará en el directorio de aplicaciones un directorio con el mismo nombre que el fichero WAR, y donde se habrán descomprimido todos sus ficheros (por eso decíamos que no podía haber subdirectorios previos en el fichero WAR, porque entonces se habría descomprimido con esos subdirectorios). 
• Con esto ya podemos llamar a la aplicación de la misma forma que se llamaría sin el WAR.