Instalación y Configuración de Software
- El Ambiente de Desarrollo

Así como el script de arranque del servidor define el CLASSPATH del servidor para incluir el servlet, las clases JSP estándard, y el directorio WEB-INF/classes (el cual contiene los servlets compilados) de cada aplicación Web, de la misma forma, uno debe crear definiciones similares para las aplicaciones que se vayan desarrollando antes de poder llegar a compilar servlets.

Para poder crear estas definiciones, resulta fundamental conocer la estructura o jerarquía de directorios subyacente a las aplicaciones Web.


1. Estructura de una Aplicación Web

Una aplicación Web se define como una jerarquía de directorios y distribución de archivos (imágenes, archivos HTML, servlets, páginas JSP, etc.) en esos directorios, bajo una estructura estándard, y que están mapeados (esto es, asignados) a un prefijo URI específico. Esta jerarquía puede ser accesada en su forma desempacada, donde cada directorio y archivo existe de forma separada, o puede ser accesada en una forma empacada conocida como Archivo Web (Web ARchive -o archivo WAR). La forma desempacada suele usarse durante la fase de desarrollo, mientras que la forma empacada es útil cuando se va a desplegar la aplicación.

Para facilitar la creación del archivo WAR en el formato requerido, es conveniente organizar los archivos "ejecutables" (los archivos que el servidor va a estar utilizando cuando se inicie la aplicación) de la aplicación Web en la misma forma en que los requiere el formato WAR.

Nota:  Se requiere que todos los servidores que se conformen a la especificación 2.2, acepten un Archivo Web (WAR) en un formato estándard.

El documento raíz (document root) de una aplicación Web corresponde con el directorio de nivel más alto en la jerarquía de directorios de una aplicación Web. En este directorio se colocan los archivos HTML y páginas JSP que conforman el interface de usuario de la aplicación.

A continuación se muestra la estructura y contenido del directorio documento raíz como los requiere el formato WAR:

Independientemente de las aplicaciones Web que uno pueda desarrollar, el servidor Tomcat incluye una aplicación Web por omisión: /webapps/ROOT.

Al inicio del aprendizaje mucha gente utiliza la aplicación Web por omisión para colocar el código desarrollado. Esto se hace colocando las páginas en cualquiera de las siguientes rutas:

Para utilizar una aplicación propia, el código desarrollado se coloca en una ruta como la siguiente:

El siguiente cuadro muestra gráficamente cómo luce la jerarquía de directorios de las aplicaciones Web, lo cual permite visualizar todo el concepto explicado. En él se ejemplifican dos aplicaciones Web: La aplicación Web por omisión (ROOT), y una aplicación Web personal (MiApWeb):

dir_tom
    |
    +-- webapps
        |
        +-- ROOT                             -- Aplicación Web por Omisión - Documento Raíz
        |   |
        |   +-- images
        |   |
        |   +-- WEB-INF
        |       |
        |       +-- classes
        |       |   |
        |       |   +-- paquetes
        |       |
        |       +-- lib
        |
        :
        |
        +-- MiApWeb                           -- Aplicación Web Personal - Documento Raíz
        |   |
        |   +-- images
        |   |
        |   +-- WEB-INF
        |       |
        |       +-- classes
        |       |   |
        |       |   +-- com
        |       |       |
        |       |       +-- micompañia
        |       |           |
        |       |
        |       +-- lib

Nota:  En todas las versiones de Tomcat 4, la localización para los servlets en la aplicación Web por omisión es: /webapps/ROOT/WEB-INF/classes. Sin embargo, en las últimas versiones de Tomcat, el sistema no crea el directorio automáticamente, uno tiene que crearlo. Ojo: "classes" va en minúscula!

Aunque toda la explicación anterior puede parecer algo extensa, es importante asimilar este concepto, ya que de ello dependerá el éxito o fracaso de desarrollar, mantener y desplegar correctamente aplicaciones Web.

Nota:  Cuando una aplicación Web es instalada en un servidor, se dice que ésta es desplegada (deployed). Cuando una aplicación es desplegada, generalmente una trayectoria contextual (context path) le es asignada hacia la misma. Por ejemplo, si la trayectoria contextual /juegos, se asigna a una aplicación Web, entonces un URI de petición refiriéndose a /juegos/index.html regresará el archivo index.html del documento raíz.

En caso de optar en un principio por no hacer aplicaciones independientes, sí es imperativo que las páginas y código que se desarrollen, se desplieguen en la aplicación Web por omisión (dir_tom/webapps/ROOT/WEB-INF/classes). Existen dos razones (incluso más) para hacerlo así:

  1. Es estándard, esto es, el directorio ROOT sigue la estructura de una aplicación Web:
    • Los archivos HTML/JSP van en el documento raíz;
    • El archivo web.xml va en el directorio WEB-INF;
    • Las clases sin empacar (esto es, no convertidas en archivos JAR), van en el directorio WEB-INF/classes;
    • Las clases empacadas (esto es, convertidas en archivos JAR), van en el directorio WEB-INF/lib.

    Así, si se utiliza WEB-INF/classes, uno está utilizando una estructura que funciona con todos los servidores que soporten Servlet 2.2 y posteriores.

    Mientras que desplegar la aplicación en algún otro directorio (por ejemplo, dir_tom/shared/classes), implica que se está utilizando una ruta específica del servidor y que sólo será soportada por unos cuantos servidores.

  2. Es específica para una aplicación Web, esto es, una vez que uno se familiariza con lo básico, uno ciertamente va a desear dividir sus proyectos en diferentes aplicaciones Web.

    Al colocar el código en WEB-INF/classes, uno automáticamente ya está listo para hacerlo, ya que por definición, ese código ya forma parte de una aplicación Web: La aplicación Web por omisión del Tomcat, por lo que este código puede ser fácilmente movido a otra aplicación Web y no interferirá con futuras aplicaciones desarrolladas.

    Por otro lado, el código colocado en algún otro directorio (por ejemplo, dir_tom/shared/classes), es código que es compartido por todas las aplicaciones Web del servidor, lo cual (generalmente) no es lo que uno realmente desea hacer.

2. Crear un Directorio de Desarrollo

Tal como se recomienda una jerarquía de directorios para las aplicaciones Web desplegadas, de la misma forma se recomienda una jerarquía de directorios para el código fuente de una aplicación Web. Aunque en principio uno como desarrollador tiene la libertad de organizar los directorios fuente como lo desee, resulta muy conveniente seguir las recomendaciones, ya que a la larga eso resulta en menos trabajo de organización.

Las ventajas de seguir las recomendaciones se aprecian cuando uno empieza a manejar tanto proyectos más grandes, como cuando se empiezan a manejar herramientas complejas para ayudar en el desarrollo (IDE‘s, "Ant", etc.). En cualquier caso, tarde que temprano -y por mucho que uno desee evitarlo-, uno tiene que aprender y manejar estas formas de organización. Así, al mal paso darle prisa, el siguiente diagrama muestra la jerarquía recomendada para el ambiente de desarrollo:

Aplicación/
    |
    +-- docs                                 -- documentación de la aplicación
    |
    +-- src                                  -- directorio base para el código fuente
    |   |
    |   +-- paquete
    |       |
    |       +-- subpaquete
    |           |
    |           +-- sub-subpaquete
    |
    |
    +-- web                                  -- Documento Raíz
        |
        +-- images
        |
        +-- WEB-INF

Vale la pena hacer un comentario final sobre este tema, y es que suele ser un error común el colocar todo el código (tanto los archivos fuente como las clases compiladas), en el directorio de despliegue del servidor, esto es, trabajar directamente en los directorios de despliegue en lugar de manejar el código fuente en directorios de desarrollo, y las clases compiladas en los directorios de despliegue. Esto en un principio puede parecer más sencillo de hacer, sin embargo, a la larga complica significativamente todo el proceso de mantenimiento y despliegue de las aplicaciones.

Entonces, para empezar correctamente y crear buenos hábitos desde un principio, haremos nuestro directorio de desarrollo como se recomienda. Empezaremos con la siguiente estructura básica:

Haremos esta jerarquía bajo la ruta D:\Dev.


  D:\Dev
     |
     +-- curso_jsp
         |
         +-- src
         |
         +-- web
             |
             +-- WEB-INF

Nota:  A partir de este punto, me referiré a la ruta: D:\Dev\curso_jsp como dir_code.

Aprovechando que en el siguiente punto vamos a modificar el archivo autoexec.bat, vamos a aprovechar para definir una variable que es exclusivamente para uso interno del curso. Definiremos la variable de ambiente G_DST, de tal forma que ésta apunte al directorio base que acabamos de crear.

Si el directorio base creado fue D:\DEV\CURSO_JSP, entonces definiremos G_DST como:

SET G_DST=D:\DEV\CURSO_JSP

Nota:  Esta variable la van a utilizar algunos de los programas de instalación del CD.

3. Definir Nuestra Variable CLASSPATH

Puesto que los servlets y JSP no son parte de la plataforma Java 2 -Edición Estándard-, uno tiene que indicar la localización de las clases servlet al compilador. El servidor ya sabe de las clases servlet, mas no así el compilador (javac). Por ello, si uno no define la variable CLASSPATH, cualquier intento de compilar servlets, bibliotecas de etiquetas o cualquier otra clase que utilice el API de servlets, va a fallar con mensajes de error sobre clases no conocidas.

Nota:  Olvidar definir la variable CLASSPATH es uno de los principales errores cometidos como principiante.

La localización exacta del archivo JAR de servlets varía de servidor a servidor. En Tomcat, éste se encuentra en: dir_tom/common/lib/servlet.jar.

Ahora también es necesario incluir nuestro directorio de desarrollo en el CLASSPATH. Aunque esto no es necesario para servlets sencillos que no usen paquetes, con el tiempo seguramente se harán servlets que sí los usen. El compilar un archivo que esté en un paquete y que utilice otra clase del mismo paquete, requiere que CLASSPATH incluya al directorio base de la jerarquía de paquetes. En nuestro caso éste corresponde con el directorio del código fuente (D:\Dev\curso_jsp\src).

Finalmente (aunque ya se hizo previamente), uno debe incluir también al directorio actual (".\") dentro de CLASSPATH. De otra forma, uno sólo podría compilar clases sin paquetes que estén en el nivel más alto del directorio de desarrollo.

Para definir la variable CLASSPATH, vamos a cambiar la línea que habíamos colocado en nuestro archivo autoexec.bat:

set CLASSPATH=.\;

para que ahora quede así:

set CLASSPATH=.\;
  D:\Dev\curso_jsp\src;C:\Adt\Tomcat\common\lib\servlet.jar

Nota:  Para fines de presentación la línea anterior se dividió. En realidad debe ser continua.

4. Accesos a los scripts de Arranque y Alto del Tomcat

En caso de que no se haya configurado el archivo dir_tom/conf/server.xml para Activar la Recarga de Servlets, uno va a encontrarse frecuentemente apagando y reiniciando el servidor. Así, para evitar estar navegando por el explorador de windows buscando los scripts de arranque y alto del tomcat, existen algunas opciones:

  1. Se pueden colocar accesos directos a los scripts de arranque y alto del Tomcat, ya sea en el escritorio, en la barra de lanzamiento rápido o en la barra de office.

    Suponiendo que se opta por la segunda opción:

    • En dir_tom/bin, hacemos click con el botón derecho del ratón sobre startup.bat, y elegimos Crear acceso directo.
    • Repetimos el mismo proceso para shutdown.bat.
    • Cortamos (Ctrl-X) los dos accesos creados, nos dirigimos al folder de lanzamiento rápido:
      C:\WINDOWS\Application Data\Microsoft\Internet Explorer\Quick Launch,
      y pegamos (Ctrl-V) ahí los accesos.
  2. Se pueden hacer en el directorio de desarrollo de la aplicación (dir_code), scripts que llamen a los scripts de arranque y alto del Tomcat.

    Para el script de arranque salvamos el siguiente código en dir_code con el nombre tomcat-start.bat:

    @echo off
    C:
    cd \Adt\Tomcat\bin
    call startup.bat
    D:
    

    Para el script de alto salvamos el siguiente código en dir_code con el nombre tomcat-stop.bat:

    @echo off
    C:
    cd \Adt\Tomcat\bin
    call shutdown.bat
    D:
    

5. Referenciar la Documentación API

Durante el desarrollo de servlets y páginas JSP, resulta conveniente tener una liga directa al API de las clases en los paquetes javax.servlet. Para ello abrimos en nuestro navegador la página dir_tom/webapps/tomcat-docs/servletapi/index.html y la agregamos a nuestra lista de bookmarks (Netscape), o a la de favoritos (Internet Explorer).

En caso de que el servidor Tomcat está corriendo, el API también puede ser accesado por medio de http://localhost/tomcat-docs/servletapi/index.html.

Queda así finalizada la configuración de nuestro ambiente de desarrollo.

Ahora sí, reiniciamos el equipo para poder hacer las últimas pruebas sobre el Tomcat.


Ayuda

Para más información sobre Tomcat: