Apache Tomcat: Habilitando SSI

Parece que por defecto la instalación de Apache Tomcat no trae habilitado los SSI (Server Side Includes). Para habilitarlo hay que hacer tres pasos sencillos:

1. Renombrar el JAR que se encuentra en "[catalina_home]/server/lib": servlets-ssi.renametojar
2. Descomentar la configuración del servlet en "[catalina_home]/conf/web.xml"

<!--
  <servlet>
<servlet-name>ssi</servlet-name>
<servlet-class>
org.apache.catalina.ssi.SSIServlet
</servlet-class>
<init-param>
<param-name>buffered</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>666</param-value>
</init-param>
<init-param>
<param-name>isVirtualWebappRelative</param-name>
<param-value>0</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>
-->

3. Descomentar la configuración del mapeo del servlet en el mismo archivo y configurar el patrón URL como corresponde al tipo de extensiones que van a tener estos includes

<!--
  <servlet-mapping>
<servlet-name>ssi</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
-->

Autenticación en Tomcat para acceso de direcciones de tipo UNC

Estuve lideando con un problema que me tomó un par de días resolver. Tengo un código en Java que utilizó para listar los archivos dentro de una carpeta. Uno simplemente crea una instancia de la clase java.io.File pasando en el constructor la ruta de la carpeta. Después solamente se llama el método "listFiles" y te retorna un arreglo con los archivos encontrados.

La ruta que necesitaba listar era de tipo UNC. La sintaxis utilizada por Microsoft para accesar una localidad de red compartida. Esta ruta estaba protegida con usuario y contraseña en el servidor. No obstante estos ya estaban guardados por windows de manera que no me volvía a preguntar por ellos cada vez que accesaba la dirección de red.

El problema en sí era que la clase de abajo (no es la misma, solo para usos de ejemplificación) funcionaba correctamente si la ejecutaba en línea de comandos. Pero si la usaba en mi aplicación web corriendo en Tomcat, la misma carpeta no se podía encontrar.

import java.io.File;

public class FolderLister {

public File[]listFiles(String address) {
File folder = new File(address);

if(folder.exists()) {
return file.listFiles();
}
return null;
}

public static void main(String [] args) {

FolderLister folderLister = new FolderLister();

File[] listOfFiles = folderLister.listFiles("\\\\remote-host\\path");

for (File f : listOfFiles) {
System.out.println(f.getName());
}
}
}

Intenté probar con el "catalina.policy" pero me di cuenta que nada tenía que ver con mi problema. Después de googlear con las palabras correctas encontré un foro donde indicaban que el Tomcat tenía que ser arrancado con el usuario que tenía acceso a la carpeta compartida. Esto se puede configurar fácilmente en las propiedades del servicio en la pestaña de "Log On".

¿Recargar o no recargar?

He notado que varios compañeros de equipo configuran en Tomcat la aplicación en la que trabajamos con el atributo "reloadable" en "true".

<Context path="/miaplicacion" reloadable="true" docBase="C:\MiAplicacion" />

Este atributo causa un comportamiento que para mi es bastante incómodo a la hora de estar desarrollando y haciendo pruebas con la aplicación localmente. Si uno tiene arriba el tomcat y desea modificar el código un poco para ver si esa pulga que tenemos se resuelve, uno tiene que esperar para arrancar de nuevo el servidor ya que cualquier cambio al código de la aplicación produce automáticamente un reinicio del servidor.

Curiosamente la página de Apache Tomcat recomienda habilitar esta opción para desarrollo:

"Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development..."

Supongo que debe ser útil si uno constantemente actualiza el código desde un repositorio central y necesita que la aplicación sea refrescada con los últimos cambios. La verdad no estoy seguro qué es lo que se gana exactamente, pero en mi experiencia es preferible no habilitarla pues es cansado sobre todo si la aplicación requiere de un tiempo significativo para reiniciar.

Cuando dejamos el atributo reloadable="false" nuestro código con solo ser guardado podrá reflejar los cambios en la aplicación en vivo con la excepción de que los cambios no sean sobre la "firma" de la clase. Si se cambian miembros de clase o los parámetros de entrada o salida de cualquier método, la aplicación forzamente tiene que ser reiniciada.

Esa ha sido al menos mi experiencia con Eclipse, quizás algún otro IDE se comporte diferente pero supongo que debe ser una norma general al tratarse de configuración de Tomcat. Mi recomendación es apagar esta opción y si notan que un cambio no se está viendo reflejado o la aplicación se comporta extraño, entonces manualmente se reinicia el servidor.

Análizando el desempeño de nuestra aplicación web con Eclipse TPTP

Usar una herramienta de profiler (perdón por el anglisismo pero no encuentro una término adecuado en español, se puede decir "perfilador" supongo) es una buena manera de encontrar esos cuellos de botella de nuestra aplicación web.

Hoy quisiera recomendar una herramienta que he utilizado en el pasado. Puede que hayan otras más adecuadas dependiendo del tipo de análisis que se quiera efectuar, pero por ahora describiré rápidamente la que conozco: TPTP (Test and Perfomance Tools Platform) o "Prueba y Plataforma de Herramientas de Desempeño".

En mis propias palabras, un profiler es una herramienta que nos permite tener datos estadísticos para probar aquello que ya sabíamos antes (talvez de manera intituiva) por mucho tiempo, pero necesitabamos alguna herramienta sofisticadilla para culpar el mal desempeño de un código, esperando que no sea el que creamos nosotros :). Poniéndonos serios, el uso de estas herramientas para recopilar datos y resumirlos por nosotros realmente nos quita una carga cuando necesitamos apuntar de manera certera, qué parte de nuestra aplicación está degradando el desempeño.

Primero descargamos e instalamos TPTP en Eclipse. Puede ser descargado en un paquete "todo-en-uno" con la versión Galileo.

Abrimos el proyecto al que deseamos crear el perfil ("profile") y usamos la opción "profile" para comenzar el proyecto:

Clic derecho en el proyecto -> “Profile As“ -> “Profile Configurations...”



Seleccionar la opción de “Tomcat 5.x”:



Seleccionar el tipo de análisis. En este caso estamos seleccionando el Análisis de Tiempo de Ejecución (“Execution Time Analysis”).



Seleccionamos Editar Opciones ("Edit Options") para seleccionar el nivel de detalle del análisis:

Hay algunas otras opciones que pueden ser configuradas pero las dejamos a exploración del lector. Finalmente damos clic on "Profile". Eclipse iniciará el servidor Tomcat y la perspectiva "Profiling and Logging" se abrirá.

Doble clic en "Execution Time Analysis" para abrir la tabla de resumen:

Una vez que el profiler está corriendo, necesitamos navegar localmente en el sitio para que la mayoría, o al menos las partes de interés, de nuestro código sea examinado y así recolectar todos los datos de las diferentes clases de la aplicación.

Este análisis mide la cantidad de tiempo (en segundos) consumido por cada método de cada clase. En la tabla de resumen solamente los 10 primeros paquetes más altos en tiempo base ("base time") son mostrados. No obstante se puede ver el detalle de todos lo paquetes ejecutados si se desea.

Tiempo base (Base Time): La cantidad de tiempo (en segundos) que un método especifico acumuló en todas las llamadas de la apliación. Esto no incluye el tiempo de ejecución de otros métodos anidados (sub llamados a otros métodos).

Tiempo promedio base: (Average base time): Es el tiempo base divido entre el número total de llamados hechos por la aplicación.

Tiempo base acumulado (Cumulative base time): La cantidad de tiempo (en segundos) que al método le toma ejecutarse incluyendo todos los sub llamados hechos por el mismo.
Siempre: Tiempo base acumulado >= Tiempo base (Base Time)

Cabe concluir diciendo que esta operación de recolección de datos por parte del profiler es una operación sumamente pesada que consume muchos recursos del equipo dependiendo de lo complejo de la aplicación web. Es recomendable no hacer otras cosas en el equipo porque sino, por experiencia propia, el Eclipse tiende a congelarse y no responder más.

Tu Primer Proyecto Web con Eclipse & Tomcat

Tu primer proyecto web usando Eclipse y Tomcat

Requerimientos:

1. Instalación de Tomcat (Descarga).
2. Eclipse IDE. En este post usaré EasyEclipse Expert Java Version: 1.3.1.1 (Descarga).

Siguiendo la línea "Para Newbies", explicaré en cortos pasos una manera rápida de crear tu primer proyecto web con java usando Eclipse como IDE y Tomcat como servidor web. En este caso no se usará un "Super Wizard" para configurar el proyecto sino que se seguiran ciertos pasos manuales para
entender un poco lo que se está haciendo.


1. Primero tenemos que crear nuestro proyecto Java.

File -> New -> Java Project





2. Ahora creamos una clase simple que sera invocada por nuestro código JSP.

Clic derecho en el directorio "src" -> New -> class
Right click on “src” folder ->New ? class

package newbie;  

public class HolaMundo {
public static String getHola() {
   return "Hola From Costa Rica, Pura Vida!!!";
}
}

3. Es tiempo de crear la estructura de nuestro directorio "WebContent". Para este simple caso crearemos la siguiente estructura:

HolaMundo
+WebContent
++ pages
++ WEB-INF

4. Dentro del directorio WEB-INF agregaremos un archivo llamado "web.xml". Por el momento vamos a dejarlo simple, pero en el futuro, a medida en que crezca el proyecto, más configuraciones se agregaran a este archivo.

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<!--> More Settings Here <-->

</web-app>

5. Dentro del directorio de "pages" agregaremos un JSP llamado “HolaMundo.jsp”:

<%@ page import="newbie.HolaMundo" %>
<%
String message = HolaMundo.getHola();
%>
<h1><%=message%></h1>

El código de este JSP basicamente incluye nuestra clase Java y despliega el String retornado por el método "getHola()".

6. Antes de configurar nuestro Tomcat necesitamos configurar nuestro "build path". Por defecto Eclipse establece el directorio de salida o "outout folder" (donde los "*.class" para cada uno de los "*.java" se localizan) in "<nombre_proyecto/bin>". Ya que nuestro proyecto es web, necesitamos mover el path a:

“HolaMundo/WebContent/WEB-INF/classes”

Clic derecho en el proyecto ->Build Path-> Configure Build Path... ->Source Tab



7. El último paso es configurar nuestro Tomcat. La manera más fácil es simplemente abrir el archivo "server.xml" localizado en:

<Tomcat Installation>\conf\server.xml

y agregar las siguientes líneas entre las etiquetas “<Host> </Host>”

<Context path="/HolaMundo" reloadable="false" docBase="E:\HolaMundo\WebContent" />

El atributo "path" es un path virtul que apunta a nuestro proyecto indicado por el atributo "docBase".

Si todo fue hecho correctamente lo único que resta es arrancar nuestro Tomcat. Es recomendado instalar un plugin a eclipse, "Tomcat Launcher Plugin", para facilitar las tareas de arrancar y parar el servidor.

Normalmente Tomcat corre en el puerto 8080: