Section 2: The Structure and Deployment of Web Applications



 

2.1 Construct the file and directory structure of a Web Application that may contain (a) static content, (b) JSP pages, (c) servlet classes, (d) the deployment descriptor, (e) tag libraries, (d) JAR files, and (e) Java class files; and describe how to protect resource files from HTTP access.

Los web servers tienen una ubicación por default, donde se van a instalar las aplicaciones. En TOMCAT, este directorio es <TOMCAT INSTALLATION DIRECTORY>/webapps, pero puede ser modificado a donde se necesite. Dentro de este directorio, cada aplicación tendrá un directorio. A este directorio se lo llama 'Context Root' e identifica el home directory de la aplicación.

Inmediatamente debajo del Context Root, se pueden ubicar un conjunto de recurso, tales como páginas web (html, htm), JSPs, imagenes(gif, jpg), hojas de estilo(css), etc. Estos recursos pueden estar tambien en directorios. Todo lo que esta aquí es accesible para cualquier usuario de la aplicación.

Debajo del 'Context Root' además se encuentra un directorio sumamente importante, llamado 'WEB-INF'. Este directorio no es accesible directamente por el usuario (es decir que si el usuario intenta acceder directamente, recibe un error 404). En este directorio encontramos un archivo, llamado 'Deployment Descriptor' (web.xml) que 'define' muchisimos aspectos de la aplicación.

** Si este directorio no existe, los archivos estaticos que se deployeen en el context root pueden ser accedidos. Sin embargo, si solo ponemos el contexto root en la URL no se buscará automaticamente el index.html. Con solo poner el archivito web.xml con lo mínimo (<web-app></web-app>) ya se buscará el archivo index.html como default.

Además, en este directorio encontramos los siguientes directorios:

- /WEB-INF/classes: servlets o POJOs se encuentran en este directorio, gralmente. siguiendo la estructura de paquetes estandar de Java (aunque pueden estar directamente abajo, si pertencen al paquete estandar).

/WEB-INF/lib: Archivos JAR que soportan la aplicación (por ejemplo, el driver de la BD).

* El classloader carga primero las clases del directorio 'classes' y despues las del directorio 'lib'.

2.2 Describe the purpose and semantics of the deployment descriptor

El deployment descriptor es un archivito xml que define la estructura de la aplicación web. Entre los puntos que se definen estan: los archivos de bienvenida, los servlets, la página de error, etc. 

2.3 Construct the correct structure of the deployment descriptor

Todo archivo xml necesita un root. Para el caso del deployment descriptor, el root es <web-app></web-app>. Este es el único elemento mandatorio en el deployment descriptor. Debajo de este elemento, pueden haber 27 tags, todos ellos opcionales. Ahora vamos a estudiar los elemenos más importantes del primer nivel.

Elemento <servlet>

Todos los servlets que construyamos, necesitan una entrada en el deployment descriptor. Esta entrada define el nombre, como se mapea en el context root, cual es la clase que lo implementa, etc...

Estos son los subelementos más importantes de <servlet>

<servlet-name> - El nombre del servlet es usado por el mecanismo de accesso a controlado a WEB-INF (a través del tag servlet-mapping). Ademas, puede ser accedido desde la clase que lo implementa (2 servlets - osea 2 nombres diferentes - pueden ser implementados por la misma clase. A través de este método se puede averiguar de cual de las instancias estamos hablando)

<servlet-class> - El nombre completo de la clase que implementa el servlet. Esta clase obviamente tiene que ser descendiente de GenericServlet o HttpServlet.

<jsp-file> - Este tag sirve para acceder jsp's que estan bajo el directorio WEB-INF.

<init-param> - Este tag sirve para incluir parametros que serán enviados al servlet. El formato es el siguiente:

<init-param>
     <description>blah blah blah</description>
     <param-name>Nombre</param-name>
     <param-value>Jose</param-value>
</init-param>

** Dentro del servlet, podremos recuperar estos valores utilizando estos 2 métodos:

java.lang.String

getInitParameter(java.lang.String name)

Returns a String containing the value of the named initialization parameter, or null if the parameter does not exist.

java.util.Enumeration getInitParameterNames()
Returns the names of the servlet's initialization parameters as an Enumeration of String objects, or an empty Enumeration if the servlet has no initialization parameters.

<load-on-startup> - Este tag sirve para especificar un order de carga para el servlet. Un servlet con un número positivo mayor que otro se carga primero (si es negativo o no existe, no podemos asegurar un order de carga - generalmente se carga cuando es accedido - )


Elemento <servlet-mapping>

Este tag nos permite mapear un servlet lógico con una URL. El formato es el siguiente:

<servlet-mapping>
   <servlet-name>MiServlet</servlet-name>
   <url-pattern>/miservlet</url-pattern>
</servlet-mapping>

En general, el url-pattern se pone como el ejemplo, es decir identificando una URL única. Sin embargo, podemos ponerlo tbn. de otras formas:

Poniendo el camino: /path/morepath/*        -       path/morepath/yetanothepath/index.html

Poniendo todos los archivos que tengan la extension: *.jsp        -       index.jsp

** Primero busca los que coinciden perferctamente, despues por el path, después por la extensión y finalmente el default (/).

Otros elementos

<welcome-file-list> - sirve para especificar una lista de URLs, que serán apendeados a la URL recibida en el request y en caso de hacer matching, retornadas al solicitante.

El formato es el siguiente:

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

<error-page> - es posible especificar páginas de error por default, que serán devueltas y mostradas al usuario(el browser no mostrará la clásica página de error 404 por ejemplo) cuando el recurso solicitado no existe o cuando el servlet arroja una excepción.

<error-page>
   <error-code>404</error-code>
   <location>/MiPaginadeerror.html</location>
</error-page>

or

<error-page>
   <exception-type>javax.servlet.ServletException</exception-type>
   <location>/customErrorPage.html</location>
</error-page>

<mime-mapping> - este tag sirve para asociar en el descriptor una extension con un mime type (para que el requester sepa que hacer con el archivo)

<mime-mapping> 
   <extension>txt</extension> 
   <mime-type>text/plain</mime-type> 
<mime-mapping> 

2.4 Explain the purpose of a WAR file and describe the contents of a WAR file, how one may be constructed.

Los archivos .war (web archive) son un mecanismo provisto para hacer el deployment de la aplicación mas facil. Cuando copiamos un archivo a war al webapps de tomcat, automaticamente tomcat lo descomprime. Un archivo war es gralmente. un archivo .zip, que puede ser visto por winzip. La herramienta provista por Sun para crear el archivo war es jar. Cuando creamos el archivo war usando esta herramienta, se crea un directorio llamado META-INF, que contiene un archivo llamado MANIFEST.MF. El uso más importante de este archivo es especificar jars externos a la aplicación que serán necesitados.