Un servlet no es más que una clase que implementa la interfaz Servlet (que se encuentra dentro del paquete javax.servlet, como todas las clases e interfaces que comentaremos) o que extiende de la clase GenericServlet, que proporciona una implementación por defecto para los métodos definidos en la primera. GenericServlet es independiente del protocolo utilizado, si nuestro servlet sólo va a usar HTTP podemos heredar de la clase HttpServlet.

Para escribir un servlet que extienda GenericServlet tendremos que sobre escribir el método abstracto service() y añadir ahí el código que queramos que se ejecute cuando se llame al servlet. En el caso de HttpServlet la implementación por defecto del método service comprueba si la petición recibida era de tipo POST (los parámetros se pasan en la cabecera del mensaje) o de tipo GET (los parámetros están en la URL, luego son visibles para todo el mundo), y llama a los métodos doPost o doGet dependiendo de esto.

Tanto doGet como doPost reciben como parámetros objetos de tipo HttpServletRequest y HttpServletResponse.

De la clase HttpServletRequest nos interesa el método getParameter(String nombreParametro), que devuelve el valor del parámetro de nombre nombreParametro. Por ejemplo, si visitáramos la URL http://localhost:8080/ejemplo/hola?nombre=Raul&apellido=Gonzalez (vemos que es una petición GET, porque los parámetros se pasan en la URL) el servlet hola podría llamar a getParameter("nombre") para obtener el nombre o getParameter("apellido") para obtener el apellido.

De HttpServletRequest también nos interesa el método getSession(boolean crear), que nos devuelve un objeto de tipo HttpSession y cuyo parámetro indica si debería crearse una sesión o no para ese usuario en caso de que no exista ya. Una sesión es el mecanismo por el cual podemos identificar una serie de iteraciones de un cliente con nuestra aplicación, y guardar y obtener valores que se mantengan para ese usuario durante las distintas peticiones que haga durante la sesión. En castellano:

1. Un usuario pide una de nuestras páginas JSP o uno de nuestros servlets, por ejemplo la página de login.
2. Se crea una cookie (también se pueden usar otros métodos) en el navegador del usuario, con un identificador aleatorio.
3. Ahora, en nuestro JSP o servlet podemos guardar valores cualquiera que podrán ser vistos por las demás páginas JSP o servlets de nuestra aplicación que visite el usuario. Por ejemplo guardamos el nombre de usuario que ha introducido.
4. Si el usuario visita otra de nuestras páginas podemos obtener el valor que guardamos en la sesión. Por ejemplo, podemos obtener el nombre de usuario que guardamos e imprimirlo en la parte superior de la página con un “Bienvenido Zootropo”.

El método de HttpSession que se utiliza para guardar objetos en la sesión es setAttribute(String nombre, Object objeto) y el método que se utiliza para obtener los objetos que guardamos, getAttribute(String nombre). No obstante hay que tener en cuenta que los objetos que guardamos en la sesión deben ser serializables (implementar Serializable).

Un concepto similar al de las sesiones sería el de contexto de Servlet. Este permite guardar y recuperar valores, pero estos valores serán comunes para todos los usuarios de la aplicación. Se representa por un objeto ServletContext que obtenemos a partir del método getServletContext() de GenericServlet y tiene métodos getAttribute y setAttribute al estilo de la sesión.

De la clase HttpServletResponse nos interesa el método getWriter(), que devuelve un objeto de tipo PrintWriter con el que escribir en el navegador usando el método println(String texto) y sendRedirect(String url), que permite enviar al navegador una instrucción de redirección a la página que deseemos.

Similar a sendRedirect es el método forward(HttpServletRequest request, HttpServletResponse response) de la clase RequestDispatcher, que se diferencia en que es más rápido, porque se trata a nivel de servidor, pero no permite redireccionar a URLs externas a la aplicación. El objeto RequestDispatcher se obtiene a partir del request mediante el método getRequestDispatcher(String url).

Tanto sendRedirect como forward no hacen más que redirecciones, es decir, su objetivo no es el de escribir parte del documento y delegar después el resto a otro servlet; ese es el cometido del método include de RequestDispatcher.

Otros métodos de HttpServlet son init(), que se lanza al iniciar el servlet, y destroy(), que se lanza cuando se destruye. Hay que tener en cuenta que, dado que el proceso de creación de un servlet es muy costoso en tiempo, no se crea un nuevo servlet para cada petición del cliente (y evidentemente tampoco se destruye cuando se termina de procesar), lo cual implica, entre otras cosas, que init() y destroy() sólo se llaman una vez y que hay que andar con pies de plomo a la hora de usar variables de instancia dado que pueden provocar problemas de concurrencia. Esto también es así en el caso de los JSP, que como ya dijimos, no son más que servlets al fin y al cabo.

La forma de un servlet típico entonces sería algo así:

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class MiServlet extends HttpServlet {
  public void init() throws ServletException {
    // Inicio
  }

  public void doGet(HttpServletRequest request, HttpServletResponse response)	throws ServletException, IOException {
    String nombre = request.getParameter("nombre");
    res.setContentType("text/html");
    PrintWriter out = response.getWriter();
    out.println("Hola" + nombre + "");
    out.close();
  }

  public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    try{
      doGet(request, response);
    }catch (Exception e){
      e.printStackTrace();
    }
  }

  public void destroy() {
    // Fin
  }
}

Apache y Tomcat en Linux

La instalación de Apache y Tomcat en Windows no tiene mayor complicación, basta con ejecutar los instaladores que podemos encontrar en sus respectivas webs (Apache / Tomcat). La instalación del módulo conector tampoco tiene misterio, y es similar a lo que ya vimos en Linux.

El conector puede descargarse en la misma web de Tomcat; no tenemos más que seleccionar el mirror a utilizar, la versión binaria de mod_jk (JK 1.2 Binary Releases) y descargar el archivo .so correspondiente a la versión de Apache que instalamos.

Copiaremos este archivo en la carpeta modules de Apache, renombrándolo como mod_jk.dll

La configuración es casi calcada a la de Linux. Crearemos un archivo workers.properties en la carpeta conf de Apache con el siguiente contenido:

workers.tomcat_home=Directorio en que instalamos Tomcat
workers.java_home=Directorio en que instalamos el JDK
ps=\
worker.list=default

worker.default.port=8009
worker.default.host=localhost
worker.default.type=ajp13
worker.default.lbfactor=1

Y editamos el archivo de configuración de Apache (httpd.conf en la carpeta conf) para que se cargue el módulo al iniciar el servidor. En la sección LoadModules añadimos:

LoadModule jk_module modules/mod_jk.so

Y al final del archivo:

JkWorkersFile "conf/workers.properties"
JkLogFile "logs/mod_jk.log"
JkLogLevel warn

JkMount /servlets-examples default
JkMount /servlets-examples/* default

JkMount es la línea que indica a Apache que solicitudes reenviar a Tomcat. En este caso llamaremos a Tomcat siempre que se intente acceder a cualquier archivo del directorio servlets-examples, donde se guardan algunos ejemplos para demostrar el uso de Servlets, utilizando el protocolo definido por “default”.

Por último iniciamos Tomcat y Apache. Al introducir la URL http://localhost deberíamos ver la web de bienvenida de Apache, al introducir http://localhost:8080 la de Tomcat, y con http://localhost/servlets-examples Apache enviará la petición a Tomcat.

Apache y Tomcat en Windows

Tomcat es un contenedor de servlets (es lo que necesitamos para ejecutar JSP y Servlets) creado por la fundación Apache dentro del proyecto Jakarta. Aunque se puede utilizar como servidor web no está tan optimizado como el servidor web de la misma fundación, Apache. El siguiente tutorial tiene como objetivo mostrar cómo lograr que las peticiones a Apache se redirijan a Tomcat utilizando un conector (en este caso jk). A lo largo del tutorial se compilarán los paquetes a partir del código fuente, en lugar de utilizar precompilados, por lo que debería poder seguirse facilmente utilizando cualquier distribución.

Instalación del JDK

Evidentemente lo primero que necesitamos para desarrollar en Java es instalar el kit de desarrollo (JDK) que podemos descargar desde la web de Sun. A la hora de escribir este tutorial la última versión es la 5.0 Update 6. Utilizaremos la versión autoextraible (Linux self-extracting file) en lugar del paquete RPM.

su
Introducir contraseña de root
cp -p jdk-1_5_0_06-linux-i586.bin /usr/local
cd /usr/local
chmod +x jdk-1_5_0_06-linux-i586.bin
./jdk-1_5_0_06-linux-i586.bin
rm jdk-1_5_0_06-linux-i586.bin


Esto extraerá el contenido del archivo en una nueva carpeta jdk1.5.0_06 en /usr/local. Ahora basta crear la variable de entorno para indicar dónde está instalado el JDK y añadir a la variable PATH el directorio en el que se encuentran los binarios para poder ejecutarlos desde cualquier sitio. Para ello abrimos el archivo /etc/profile con nuestro editor favorito (como root) y añadimos las siguientes líneas al final:

JAVA_HOME=/usr/local/jdk1.5.0_06
PATH=$PATH:$JAVA_HOME/bin
export PATH JAVA_HOME

Actualizamos las variables de entorno:

source /etc/profile

Si todo ha salido bien al escribir javac -version deberíamos obtener el número de versión del compilador de Java. En el caso de que algo halla salido mal el sistema nos informará de que no encontró ningún ejecutable con ese nombre.

Compilar e instalar Apache

Descargamos el código fuente de la aplicación desde la web de la fundación. Descomprimimos, compilamos e instalamos:

cp -p httpd-2.2.0.tar.gz /usr/local/src/
cd /usr/local/src
tar xvzf httpd-2.2.0.tar.gz
rm httpd-2.2.0.tar.gz
cd /usr/local/src/httpd-2.2.0
./configure --prefix=/usr/local/apache --enable-module=most --enable-mods-shared=most
make
make install

Con esto habremos instalado Apache en /usr/local/apache. Vamos a probar la configuración por defecto y a intentar iniciar el servidor:

/usr/local/apache/bin/apachectl configtest
/usr/local/apache/bin/apachectl start


Si todo ha funcionado correctamente deberíamos poder abrir la URL http://localhost en un navegador y ver la página de bienvenida de Apache.

Detengamos Apache hasta que instalemos Tomcat y el conector:

/usr/local/apache/bin/apachectl stop

Compilar e instalar Tomcat

Descargamos la aplicación desde su web. En este caso no tenemos más que descomprimir el archivo en el directorio que queramos, ya que se trata de una aplicación Java.

cp -p apache-tomcat-5.5.16.tar.gz /usr/local/
cd /usr/local
tar xvzf apache-tomcat-5.5.16.tar.gz
rm apache-tomcat-5.5.16.tar.gz


De nuevo vamos a editar /etc/profile para añadir la variable de entorno CATALINA_HOME:

CATALINA_HOME=/usr/local/apache-tomcat-5.5.16
export CATALINA_HOME

Y actualizamos:

source /etc/profile

Por último ejecutamos el script de iniciación de tomcat:

/usr/local/apache-tomcat-5.5.16/bin/startup.sh

Deberías ver la página de bienvenida de Tomcat introduciendo la URL http://localhost:8080 en un navegador.

Por ahora vamos a parar Tomcat

/usr/local/apache-tomcat-5.5.16/bin/shutdown.sh

En este momento tenemos instalados ambos servidores que correrían de forma independiente, con Apache escuchando en el puerto 80 y Tomcat escuchando en el 8080.

Compilar e instalar el conector JK

Existen dos versiones del conector, JK y JK2. Aunque parezca raro la versión que nos interesa instalar es la primera, ya que la segunda está descontinuada. El código fuente se puede descargar desde la web de Tomcat.

Vamos a compilar el módulo mod_jk.so (debería colocarlo en la carpeta de módulos del servidor Apache):


cp -p jakarta-tomcat-connectors-1.2.15-src.tar.gz /usr/local/src/
cd /usr/local/src
tar xvzf jakarta-tomcat-connectors-1.2.15-src.tar.gz
rm jakarta-tomcat-connectors-1.2.15-src.tar.gz
cd jakarta-tomcat-connectors-1.2.15-src/jk/native/
./buildconf.sh
./configure --with-apxs=/usr/local/apache/bin/apxs
make
make install

Y ahora sólo falta configurarlo. Creamos un nuevo archivo workers.properties en /usr/local/apache/conf con el siguiente contenido:


workers.tomcat_home=/usr/local/apache-tomcat-5.5.16/
workers.java_home=$JAVA_HOME
ps=/
worker.list=default

worker.default.port=8009
worker.default.host=localhost
worker.default.type=ajp13
worker.default.lbfactor=1


Editamos el archivo de configuración de Apache (/usr/local/apache/conf/httpd.conf) para cargar el módulo. En la sección LoadModules añadimos:

LoadModule jk_module modules/mod_jk.so

Y al final del archivo:

JkWorkersFile "conf/workers.properties"
JkLogFile "logs/mod_jk.log"
JkLogLevel warn

JkMount /jsp-examples default
JkMount /jsp-examples/* default

JkMount es la línea que indica a Apache que solicitudes reenviar a Tomcat. En este caso llamaremos a Tomcat siempre que se intente acceder a cualquier archivo del directorio jsp-examples, donde se guardan algunos ejemplos para demostrar el uso de JSP, utilizando el protocolo definido por “default”. También podríamos haber utilizado algo del estilo *.jsp para ejecutar Tomcat sólo en el caso de que los archivos terminaran con esta extensión.

Por último iniciamos Apache y Tomcat:

/usr/local/apache-tomcat-5.5.16/bin/startup.sh
/usr/local/apache/bin/apachectl start


Al introducir la URL http://localhost deberíamos ver la web de bienvenida de Apache, al introducir http://localhost:8080 la de Tomcat, y con http://localhost/jsp-examples Apache enviará la petición a Tomcat.