Tomcat

Tomcat - Introduccin
Autor: Apache Traductor: Juan Antonio Palos (Ozito)
Introduccin al Servidor de Aplicaciones Tomcat de Apache o Introduccin o Cul es la Diferencia entre Tomcat y Jserv? No es Tomcat == Jserv? o Cmo Instalar la Versin Binaria de Tomcat? o Arrancar y Parar Tomcat o La Estructura de Directorios de Tomcat o Los Scripts de Tomcat o Ficheros de Configuracin de Tomcat server.xml Arrancar Tomcat dese Otros Directorio web.xml o Configurar Tomcat para Cooperar con Apache Web Server Operacin del Servidor Web Cul es la Configuracin Necesaria Hacindolo en Apache Obtener el Mdulo Jserv (mod_jserv) Hacer que Apache sirva los Ficheros Estticos del Contexto Configurar Varias JVMs Tomcat Configurar el Hosting Virtual o Trucos de Configuracin del Mundo Real Modificar y Personalizar los Ficheros Batch Modificar las Configuraciones por Defecto de la JVM Modificar nuestros Conectores Usar Almacenes de Threads en nuestros Conectores Desactivar la Auto-Recarga de Servlets Usar el SecurityManager de Java con tomcat o Por qu usar un SecurityManager o Requirimientos del Sistema o Precacuciones o Tipos de Permisos o Qu sucede cuando el SecurityManager detecta una Violacin de Seguridad Los Workers Tomcat o Definir Workers o Configurar Propiedades del Worker Propiedades de un Worker ajp12 Propiedades de un Wroker ajp13 Propiedades de un Worker lb Propiedades de un Worker jni o Macros en Ficheros de Propiedades o El ejemplo worker.properties Tomcat y SSL o Construir Tomcat con Soporte SSL o Tomcat con Apache y mod_jk
SSL via Apache SSL Directo Verificar el Fichero de Configuracin server.xml de Tomcat Generar un Certificado SSL (RSA) para Tomcat Importar Certificados SSL Trabajar con el Servicio Jakarta para NT o Configuracin Avanzada Tomcat Dentro del Servidor Web (Windows) o Configruaciones Soportadas o Instalacin Poner jni_connect.dll bajo el directorio bin Actualizar workers.properties y aadir el worker JNI Actualizar server.xml Redirigir Contextos hacia los Workers JNI o Construir el conector dll JNI o Cmo funciona esto?
o o
Introduccin al Servidor de Aplicaciones Tomcat de Apache

Introduccin
Tomcat es un contenedor de Servlets con un entorno JSP. Un contenedor de Servlets es un shell de ejecucin que maneja e invoca servlets por cuenta del usuario. Podemos dividir los contenedores de Servlets en:
1. Contenedores de Servlets Stand-alone (Independientes) Estos son una parte integral del servidor web. Este es el caso cuando usando un servidor web basado en Java, por ejemplo, el contenedor de servlets es parte de JavaWebServer (actualmente sustituido por iPlanet). Este el modo por defecto usado por Tomcat. Sin embargo, la mayora de los servidores, no estn basados en Java, los que nos lleva los dos siguientes tipos de contenedores: 2. Contenedores de Servlets dentro-de-Proceso El contenedor Servlet es una combinacin de un plugin para el servidor web y una implementacin de contenedor Java. El plugind del servidor web abre una JVM (Mquina Virtual Java) dentro del espacio de direcciones del servidor web y permite que el contenedor Java se ejecute en l. Si una cierta peticin debera ejecutar un servlet, el plugin toma el control sobre la peticin y lo pasa al contenedor Java (usando JNI). Un contenedor de este tipo es adecuado para servidores multi-thread de un slo proceso y proporciona un buen rendimiento pero est limitado en escalabilidad 3. Contenedores de Servlets fuera-de-proceso El contenedor Servlet es una combinacin de un plugin para el servidor web y una implementacin de contenedor Java que se ejecuta en una JVM fuera del servidor web. El plugin del servidor web y el JVM del contenedor Java se comunican usando algn mecanismo IPC (normalmente sockets TCP/IP). Si una cierta peticin debera ejecutar un servlet, el plugin toma el control sobre la peticin y lo pasa al contenedor Java (usando IPCs). El tiempo de respuesta en este tipo de contenedores no es tan bueno como el anterior, pero obtiene mejores rendimientos en otras cosas (escalabilidad, estabilidad, etc.).
Tomcat puede utilizarse como un contenedor solitario (principalmente para desarrollo y depuracin) o como plugin para un servidor web existente (actualmente se soporan los servidores Apache, IIS y Netscape). Esto significa que siempre que despleguemos Tomcat tendremos que decidir cmo usarlo, y, si seleccionamos las opciones 2 o 3, tambin necesitaremos instalar un adaptador de servidor web
Cul es la Diferencia entre Tomcat y Jserv? No es Tomcat == Jserv?
Es una confusin comn, Jserv es un contenedor compatible con el API Servlet 2.0 que fue creado para usarse con Apache. Tomcat es una re-escritura completa y es un contenedor compatible con los APIs Servlet 2.2 y JSP 1.1. Tomcat utiliza algn cdigo escrito para Jserv, especialmente el adaptador de servidor para Apache, pero aqu se terminan todas las similitudes.
Cmo Instalar la Versin Binaria de Tomcat?
Muy sencillo. Deberamos:

Descargar el fichero zip/tar.gz/ desde http://jakarta.apache.org/downloads/binindex.html. Desempaquetamos el fichero en algn directorio (digamos foo). Esto debera crear un subdirectorio llamado jakarta-tomcat-3.2.1. Si no es el lugar que queremos, movemos este directorio a la localizacin deseada. Cambiamos al directorio jakarta-tomcat-3.2.1 y configuramos una nueva variable de entorno (TOMCAT_HOME) que apunte a la raz de nuestro directorio Tomcat. 1. En Win32 deberamos teclear:
2. set TOMCAT_HOME=foo\jakarta-tomcat-3.2.1
3. Sobre UNIX deberamos teclear: para bash/sh:

4. TOMCAT_HOME=foo/jakarta-tomcat-3.2.1 ; 5. export TOMCAT_HOME
para tcsh
setenv TOMCAT_HOME foo/jakarta-tomcat-3.2.1
Configuramos la variable de entorno JAVA_HOME para que apunte al directorio raz de nuestra instalacin del JDK, luego aadimos el intrprete Java a nuestra variable de entorno PATH.
Esto es todo! Ahora podemos ejecutar Tomcat y se ejecutar como un contenedor de servlets independiente (del tipo 1).
Arrancar y Parar Tomcat >
Arrancamos y paramos Tomcat usando los scripts que hay en el directorio bin: Para arrancar Tomcat ejecutamos:

Sobre UNIX:
bin/startup.sh
Sobre Win32:
bin\startup
Para parar Tomcat ejecutamos:

Sobre UNIX:
bin/shutdown.sh
Sobre Win32:
bin\shutdown
La Estructura de Directorios de Tomcat
Asumiendo que hemos descomprimido la distribucin binaria de Tomcat deberamos tener la siguiente estructura de directorios:
Nombre de Directorio bin Descripcin Contiene los scripts de arrancar/parar Contiene varios ficheros de configuracin incluyendo server.xml (el fichero de configuracin principal de Tomcat) y web.xml que configura los valores por defecto para las distintas aplicaciones desplegadas en Tomcat. Contiene varia documentacin sobre Tomcat (Este manual, en Ingls). Contiene varios ficheros jar que son utilizados por Tomcat. Sobre UNIX, cualquier fichero de este directorio se aade al classpath de Tomcat. Aqu es donde Tomcat sita los ficheros de diario. Los ficheros fuentes del API Servlet. No te excites, todava! Estoa son slo los interfaces vacos y las clases abstractas que debera implementar cualquier contenedor de servlets. Contiene aplicaciones Web de Ejemplo.
conf
doc lib logs
src
webapps
Adicionalmente podemos, o Tomcat crear, los siguientes directorios:

Nombre de Directorio Descripcin Generado automticamente por Tomcat, este es el sitio donde Tomcat sita los ficheros intermedios (como las pginas JSP compiladas) durante su trabajo. Si borramos este directorio mientras se est ejecutando Tomcat no podremos ejecutar pginas JSP. Podemos crear este directorio para aadir clases adicionales al classpath. Cualquier clase que aadamos a este directorio encontrar un lugar en el classpath de Tomcat.
work
classes
Los Scripts de Tomcat
Tomcat es un programa Java, y por lo tanto es posible ejcutarlo desde la lnea de comandos, despus de configuar varias variables de entorno. Sin embargo, configurar cada variable de entorno y seguir los parmetros de la lnea de comandos usados por Tomcat es tedioso y propenso a errores. En su lugar, el equipo de desarrollo de Tomcat proporciona unos pocos scripts para arrancar y parar Tomcat fcilmente. Nota: Los scripts son slo una forma conveniente de arrancar/parar... Podemos modificarlos para personalizar el CLASSPATH, las variables de entorno como PATH y LD_LIBRARY_PATH, etc., mientras que se genera la lnea de comandos correcta para Tomcat. Qu son esos scripts? La siguiente tabla presenta los scripts ms importantes para el usuario comn:
Nombre del Script Descripcin El script principal. Configura el entorno apropiado, incluyendo CLASSPATH, TOMCAT_HOME y JAVA_HOME, y arranca Tomcat con los parmetros de la lnea de comando apropiados. Arrancar tomcat en segundo plano. Acceso directo para tomcat start Para tomcat (lo apaga). Acceso directo para tomcat stop;
tomcat
startup shutdown
El script ms importante para los usuarios es tomcat (tomcat.sh/tomcat.bat). Los otros scripts relacionados con tomcat sirven como un punto de entrada simplificado a una sola tarea (configuran diferentes parmetros de la lnea de comandos, etc.). Una mirada ms cercana a tomcat.sh/tomcat.bat nos muestra que realiza las siguientes acciones:
Sistema Operativo

Acciones Averigua donde est TOMCAT_HOME si no se especifica. Averigua donde est JAVA_HOME si no se especifica. Configura un CLASSPATH que contiene 1. El directorio ${TOMCAT_HOME}/classes (si exsiste). 2. Todo el contenido de ${TOMCAT_HOME}/lib. 3. ${JAVA_HOME}/lib/tools.jar (este fichero jar contine la herramienta javac, que necesitamos para compilar los ficheros JSP). Ejecuta java con los parmetros de la lnea de comandos que ha
Unix
configurado un entorno de sistema Java, llamado tomcat.home, con org.apache.tomcat.startup.Tomcat como la clase de arranque. Tambin procesa los parmetros de la lnea de comandos para org.apache.tomcat.startup.Tomcat, como: 1. La operacin a ejecutar start/stop/run/etc. 2. Un path al fichero server.xml usado por este proceso Tomcat.
Por ejemplo, si server.xml est localizado en /etc/server_1.xml y el usuario quiere arrancar Tomcat en segundo plano, debera introducir la siguiente lnea de comandos:
bin/tomcat.sh start -f /etc/server_1.xml
Win32
Graba las configuraciones actuales para TOMCAT_HOME y CLASSPATH. Prueba JAVA_HOME para asegurarse de que est configurado. Prueba si TOMCAT_HOME est configurado y los valores por defecto a "." no lo estn. Entonces se usa TOMCAT_HOME para probar la existencia de servlet.jar para asegurarse de que TOMCAT_HOME es vlido. Configura la varibale CLASSPATH que contiene 1. %TOMCAT_HOME%\classes (incluso si no existe), 2. Los ficheros Jar de %TOMCAT_HOME%\lib. Si es posible, todos los ficheros jar en %TOMCAT_HOME%\lib sin incluidos dinmicamente. Si no es posible, se incluyen estticamente los siguientes ficheros jar: ant.jar, jasper.jar, jaxp.jar, parser.jar, servlet.jar, y webserver.jar 3. %JAVA_HOME%\lib\tools.jar, si existe (este fichero jar contiene la herramietna javac necesaria para compilar los ficheros JSP). Ejecuta %JAVA_HOME%\bin\java, con los parmetros de la lnea de comandos que configuran el entorno de sistema Java, llamado tomcat.home, con org.apache.tomcat.startup.Tomcat como la clase de arranque. Tambin le pasa los parmetros de la lena de comandos a org.apache.tomcat.startup.Tomcat, como: 1. La operacin a realizar: start/stop/run/etc. 2. Un path al fichero server.xml usado por este proceso Tomcat.
Por ejemplo, si server.xml est localizado en conf\server_1.xml y el usuario quiere arrancar Tomcat en una nueva ventana, debera proporcionar la siguiente lnea de comando:
bin\tomcat.bat start -f conf\server_1.xml
Restaura las configuraciones de TOMCAT_HOME y CLASSPATH grabadas prviamente.
Como podemos ver, la versin Win32 de tomcat.bat no es tn robusta como la de UNIX. Especialmente, no se averigua los valores de JAVA_HOME y slo intenta "." como averiguacin de TOMCAT_HOME. Puede construir el CLASSPATH dinmicamente, pero no en todos los casos. No puede construir el CLASSPATH dinmincamente si TOMCAT_HOME contiene espacios, o sobre Win9x, si TOMCAT_HOME contiene nombres de directorios que no son 8.3 caracteres.
Ficheros de Configuracin de Tomcat
La configuracin de Tomcat se basa en dos ficheros:

1. server.xml - El fichero de configuracin golbal de Tomcat. 2. web.xml - Configura los distintos contextos en Tomcat.
Esta seccin trata la forma de utilizar estos ficheros. No vamos a cubrir la interioridades de web.xml, esto se cubre en profundidad en la especificacin del API Servlet. En su lugar cubriremos el contenido de server.xml y discutiremos el uso de web.xml en el contexto de Tomcat.
server.xml
server.xml
es el fichero de configuracin principal de Tomcat. Sirve para dos
objetivos:
1. Proporcionar configuracin inicial para los componentes de Tomcat. 2. Especifica la estructura de Tomcat, lo que significa, permitir que Tomcat arranque y se construya a s mismo ejemplarizando los componentes especificados en server.xml.
Los elementos ms importantes de server.xml se describen en la siguiente tabla:

Elemento Descripcin El elemento superior del fichero server.xml. Server define un servidor Tomcat. Generalmente no deberamos tocarlo demasiado. Un elemento Server puede contener elementos Logger y ContextManager. Este elemento define un objeto logger. Cada objeto de este tipo tiene un nombre que lo identifica, as como un path para el fichero log que contiene la salida y un verbosityLevel (que especifica el nivel de log). Actualmente hay loggeres para los servlets (donde va el ServletContext.log()), los ficheros JSP y el sistema de ejecucin tomcat. Un ContextManager especifica la configuracin y la estructura para un conjunto de ContextInterceptors, RequestInterceptors, Contexts y sus Connectors. El ContextManager tiene unos pocos atributos que le proporcionamos con: 1. Nivel de depuracin usado para marcar los mensajes de depuracin
Server
Logger
ContextManager
2. La localizacin base para webapps/, conf/, logs/ y todos los contextos definidos. Se usa para arrancar Tomcat desde un directorio distinto a TOMCAT_HOME. 3. El nombre del directorio de trabajo. 4. Se incluye una bandera para controlar el seguimiento de pila y otra informacin de depurado en las respuestas por defecto. Estos interceptores escuchan ciertos eventos que sucenden en el ContextManager. Por ejemplo, el ContextInterceptor escucha los eventos de arrancada y parada de Tomcat, y RequestInterceptor mira las distintas fases por las que las ContextInterceptor & peticiones de usuario necesitan pasar durante su servicio. El RequestInterceptor administrador de Tomcat no necesita conocer mucho sobre los interceptores; por otro lado, un desarrollador debera conocer que ste es un tipo global de operaciones que pueden implementarse en Tomcat (por ejemplo, loggin de seguridad por peticin). El Connector representa una conexin al usuario, a travs de un servidor Web o directamente al navegador del usuario (en una configuracin independiente). El objeto connector es el responsable del control de los threads en Tomcat y de leer/escribir las peticiones/respuestas desde los sockets conectados a los distintos clientes. La configuracin de los conectores incluye informacin como: 1. La clase handler. 2. El puerto TCP/IP donde escucha el controlador. 3. el backlog TCP/IP para el server socket del controlador. Describiremos cmo se usa esta configuracin de conector ms adelante. Cada Context representa un path en el rbol de tomcat donde situanos nuestra aplicacin web. Un Context Tomcat tiene la siguiente configuracin: 1. El path donde se localiza el contexto. Este puede ser un path completo o relativo al home del ContextManager. 2. Nivel de depuracin usado para los mensaje de depuracin. 3. Una bandera reloadable. Cuando se desarrolla un servlet es muy conveniente tener que recargar el cambio en Tomcat, esto nos permite corregir errores y hacer que Tomcat pruebe el nuevo cdigo sin tener que parar y arrancar. Para volver a recargar el servlet seleccionamos
Connector
Context
la bandera reloadable a true. Sin embargo, detectar los cambios consume tiempo; adems, como el nuevo servlet se est cargando en un nuevo objeto class-loader hay algunos casos en los que esto lanza errores de forzado (cast). Para evitar estos problemas, podemos seleccionar la bandera reloadable a false, esto desactivar esta caracterstica.
Se puede encontrar informacin adicional dentro del fichero server.xml.

Arrancar Tomcat dese Otros Directorio
Por defecto tomcat usar TOMCAT_HOME/conf/server.xml para su configuracin. La configuracin por defecto usar TOMCAT_HOME como la base para sus contextos. Podemos cambiar esto usando la opcin -f /path/to/server.xml, con un fichero de configuracin diferente y configurando la propiedad home del controlador de contexto. Necesitamos configurar los ficheros requeridos dentro del directorio home:

Un directorio webapps/ (si hemos creado uno) - todos los ficheros war se expandern y todos sus subdirectorios se aadirn como contextos. Directorio conf/ - podemos almacenar tomcat-users.xml y otros ficheros de configuracin. logs/ - todos los logs irn a este directorio en lugar de al principal TOMCAT_HOME/logs/. work/ - directorio de trabajo para los contextos.
Si la propiedad ContextManager.home de server.xml es relativa, ser relativa al directorio de trabajo actual.

web.xml
Podemos encontar una detallada descripcin de web.xml y la estructura de la aplicacin web (incluyendo la estructura de directorios y su configuracin) en los captulo 9, 10 y 14 de la Servlet API Spec en la site de Sun Microsystems. Hay una pequea caracterstica de Tomcat que est relacionada con web.xml. Tomcat permite al usuario definir los valores por defecto de web.xml para todos los contextos poniendo un fichero web.xml por defecto en el directorio conf. Cuando construimos un nuevo contexto, Tomcat usa el fichero web.xml por defecto como la configuracin base y el fichero web.xml especfico de la aplicacin (el localizado en el WEB-INF/web.xml de la aplicacin), slo sobreescribe estos valores por defecto.
Configurar Tomcat para Cooperar con Apache Web Server
Hasta ahora no hemos explicado Tomcat como un plugin, en su lugar lo hemos considerado como un contenedor independiente y hemos explicado como usarlo. Sin embargo, hay algunos problemas:
1. 2. 3. 4. Tomcat no es tan rpido como Apache cuando sirve pginas estticas. Tomcat no es tan configurable como Apache. Tomcat no es tan robusto como Apache. Hay mucho sites que llavan mucho tiempo de investigacin sobre ciertos servidores web, por ejemplo, sites que usan scripts CGI o mdulos perl o php... No podemos asumir que todos ellos quieran abandonar dichas tecnologas.
Por todas estas razones es recomendable que las sites del mundo real usen un servidor web, como Apache, para servir el contenido esttico de la site, y usen Tomcat como un plugin para Servlets/JSP. No vamos a cubrir las diferentes configuraciones en profundidad, en su lugar:
1. Cubriremos el comportamiento fundamental de un servidor web. 2. Explicaremos la configuracin que necesitamos. 3. Demonstraremos esto sobre Apache. Operacin del Servidor Web
En resumidas cuentas un servidor web est esperando peticiones de un cliente HTTP. Cuando estas peticiones llegan el servidor hace lo que sea necesario para servir las peticiones proporcionando el contenido necesario. Aadirle un contenedor de servlets podra cambiar de alguna forma este comportamiento. Ahora el servidor Web tambin necesita realizar lo siguiente:

Cargar la librera del adaptador del contenedor de servlets e inicializarlo (antes de servir peticiones). Cuando llega una peticin, necesita chequear para ver si una cierta peticin pertenece a un servlet, si es as necesita permitir que el adaptador tome el control y lo maneje.
Por otro lado el adaptador necesita saber qu peticiones va a servir, usualmente basndose en algn patrn de la URL requerida, y dnde dirigir estas peticiones. Las cosas son incluso ms complejas cuando el usuario quiere seleccionar una configuracin que use hosts virtuales, o cuando quieren que mltiples desarrolladores trabajen en el mismo servidor web pero en distintos contenedores de Servlets. Cubriremos estos dos casos en las secciones avanzadas.
Cul es la Configuracin Necesaria
La configuracin ms bvia en la que uno puede pensar es en la identidad de las URLs servlet que estn bajo la responsabilidad del contenedor de servlets. Esto est claro, alguin debe conocer qu peticiones transmitir al cotenedor de servlets... Todava hay algunos tems de configuracin adicionales que deberamos proporcionar a la combinacin web-server/servlet-container:

Necesitamos proporcionar la configuracin sobre los procesos Tomcat disponibles y sobre los puertos/host TCP/IP sobre los que stos estn escuchando. Necesitamos decirle al servidor web la localizacin de la librera adaptador (para que pueda cargarla en la arrancada). Necesitamos seleccionar la informacin interna del adaptador sobre cuando log guardar, etc.
Toda esta informacin debe aparecer en el fichero de configuracin del servidor web, o en un fichero de configuracin privado usado por el adaptador. La siguiente seccin explicar cmo se puede implementar esta configuracin en Apache.
Hacindolo en Apache
Esta seccin nos ensea como configurar Apache para que trabaje con Tomcat; intenta proporcionar explicaciones sobre las directivas de configuracin que deberamos usar. Podemos encontrar informacin adicional en la pgina http://java.apache.org/jserv/install/index.html. Cuando Tomcat arranque gener automticamente un fichero de configuracin para apache en TOMCAT_HOME/conf/tomcat-apache.conf. La mayora de las veces no necesitaremos hacer nada ms que incluir es fichero (aadir Include TOMCAT_HOME/conf/tomcat-apache.conf) en nuestro fichero httpd.conf. Si tenemos necesidades especiales, por ejemplo un puerto AJP distinto de 8007, podemos usar este fichero como base para nuestra configuracin personalizada y grabar los resultados en otro fichero. Si manejamos nosotros mismos la configuracin de Apache necesitaremos actualizarlo siempre que aadamos un nuevo contexto. Tomcat: debemos re-arrancar tomcat y apache despus de aadir un nuevo contexto; Apache no soporta cambios en su configuracin sin re-arrancar. Cuando tomcat arranca, tambin se genera el fichero TOMCAT_HOME/conf/tomcat-apache.conf cuando arrancar tomcat, por eso necesitamos arrancar Tomcat antes que Apache. Tomcat sobreescribir TOMCAT_HOME/conf/tomcat-apache.conf cada arrancada para que se mantenga la configuracin peronalizada. La configuracin Apache-Tomcat usa las directivas de configuracin principales de Apache as como directivas nicas de Jserv por eso podra ser confuso al principio, sin embargo hay dos cosas que lo simplifican:
En general podemos distinguir dos familias de directivas porque las directivas nicas de jserv empiezan con un prefijo ApJServ.
Toda la configuracin relacionada con Tomcat est concentrada en un slo fichero de configuracin llamado tomcat.conf, el automticamente generado tomcatapache.conf, por eso podemos mirar en un slo fichero.
Veamos ahora un simple fichero tomcat.conf:

########################################################### # A minimalistic Apache-Tomcat Configuration File # ########################################################### # Note: this file should be appended or included into your httpd.conf # (1) Loading the jserv module that serves as Tomcat's apache adapter. LoadModule jserv_module libexec/mod_jserv.so # (1a) Module dependent configuration. <IfModule mod_jserv.c> # (2) Meaning, Apache will not try to start Tomcat. ApJServManual on # (2a) Meaning, secure communication is off ApJServSecretKey DISABLED # (2b) Meaning, when virtual hosts are used, copy the mount # points from the base server ApJServMountCopy on # (2c) Log level for the jserv module. ApJServLogLevel notice # (3) Meaning, the default communication protocol is ajpv12 ApJServDefaultProtocol ajpv12 # (3a) Default location for the Tomcat connectors. # Located on the same host and on port 8007 ApJServDefaultHost localhost ApJServDefaultPort 8007 # (4) ApJServMount /examples /root # Full URL mount # ApJServMount /examples ajpv12://hostname:port/root </IfModule>
Como podemos ver el proceso de configuracin est dividio en 4 pasos que explicaremos ahora:
1. En este paso instruimos a Apache para que carque el objeto compartido jserv (o la librera dll en NT). Esta es una directiva familiar de Apache. Si la carga fue bien y el mdulo vino de un fichero llamado mod_jserv.c (1a) podemos arrancar con el resto de la configuracin Jserv-Tomcat. 2. Este paso configura varios parmetros internos de Jserv, estos parmetros son: o Instruye a jserv para que no arranque el proceso Tomcat. Esto no est implementado todava. o Desactiva la clave secreta challenge/response entre Apache y Tomcat. De nuevo, esto tampo est implementado an. o Instruye a jserv para que copie el punto de montaje del servidor base (ver siguiente seccion) en caso de hosting virtual
Instruye a jserv para usar el nivel de log de noticia. Otros niveles de log incluidos son: emerg, alert, crit, error, warn, info y debug. 3. Este paso configura los parmetros de comunicacin por defecto. Bsicamente dice que el protocolo por defecto utilizado para la comunicacin es ajpv12 que el proceso Tomcat se ejecuta sobre la misma mquina y que escucha en el puerto 8807. Si ejecutamos Tomcat en una mquina distinta a las usada por Apache deberamos actualizar ApJServDefaultHost o usar una URL completa cuando montemos los contextos. Tambien, si configuramos los conectores Tomcat para usar un puerto distinto al 8007, deberamos actualizar ApJServDefaultPort o usar una URL completa cuando montemos los contextos. 4. Este paso monta un contexto para Tomcat. Bsicamente dice que todos los paths del servidor web que empiecen con /example irn a Tomcat. Este ejemplo ApJServMount es uno muy simple, de hecho, ApJServMount tambin puede proporcionar informacin sobre el protocolo de comunicacin usado y la localizacin donde est escuchando el proceso Tomcat, por ejemplo:
5. ApJServMount /examples ajpv12://hostname:port/root
monta el contexto /examples en un proceso tomcat que se est ejecutando en el host hostname y que escucha en el puerto nmero port.
Ahora que hemos entendido las diferentes instrucciones de configuracin en el fichero de ejemplo, cmo podramos aadirla a la configuracin de Apache? Un mtodo sencillo es escribir su contenido en httpd.conf (el fichero de configuracin de Apache), sin embargo, esto puede ser muy desordenado. En su lugar deberamos usar la directiva include de apache. Al final de fichero de configuracin de Apache (httpd.conf) aadimos la siguiente directiva:
include <full path to the Tomcat configuration file>
Por ejemplo:
include /tome/tomcat/conf/tomcat.conf
Esto aadir nuestra configuracin de Tomcat a apache, despus de haber copiado el mdulo jserv al directorio libexec de Apache (o modules en caso de Win32) y rearrancar (parar+arrancar) Apache, deberamos poder conectar con Tomcat.
Obtener el Mdulo Jserv (mod_jserv)
Como vimos anteriormente, necesitamos un adaptador de servidor Web para situarlo en Apache y redirigir las peticiones a Tomcat. Para Apache, este adaptador es una versin ligeramente modificada de mod_jserv. Podramos intentar buscarlo en http://jakarta.apache.org/downloads/binindex.html para ver si hay una versin pre-construida de mod_jserv que corresponda con nuestro sistema operativo (Normalmente hay uno para NT), sin embargo, siendo una librera nativa, no deberamos esperar que est ya (demasiados sistemas operativos, pocos desarrolladores, la vida es muy corta...) Adems, pequeas variaciones en la forma de construir la variante UNIX de Apache podran resultar en errores de enlaces dinmicos.
Realmente deberamos intentar construir mod_jserv para nuestro sistema (no te asustes, no es tan dificil!). Construir mod_jserv sobre UNIX:
1. Descargar la distribucin fuente de Tomcat desde http://jakarta.apache.org/downloads/sourceindex.html. 2. Descomprimirla en algn directorio. 3. Construir el mdulo: o Mover el directorio a jakarta-tomcat/src/native/apache/jserv/ o Ejcutar el comando para construirlo:
o apxs -c -o mod_jserv.so *.c apxs es parte de la distribucin de Apache y debera estar localizado en
nuestro APACHE_HOME/bin.
Construir mod_jserv para Win32 no es tan sencillo (ya tenemos una dll descargable para Win32). Pero si todava queremos construirlo deberamos instalar visual C++ y realizar las siguientes tareas:
1. Descargar la distribucin fuente de Tomcat desde http://jakarta.apache.org/downloads/sourceindex.html. 2. Descomprimirla en algn directorio. 3. Construir el mdulo: o Mover el directorio a jakarta-tomcat\src\native\apache\jserv o Aadir Visual C++ a nuestro entorno ejecutando el script VCVARS32.BAT. o Configurar una variable de entorno llamada APACHE_SRC que apunte al directorio source de Apache, es decir SET APACHE_SRC=C:\Program Files\Apache Group\Apache\src. Observa que el fichero make espera enlazar con CoreR\ApacheCore.lib bajo el directorio APACHE_SRC. Puedes ver la documentacin de Apache para construir ApacheCore. o Ejecutamos el comando para construir:
o nmake -f Makefile.win32 nmake es el programa make de Visual C++.
Esto es todo!, ya hemos construido mod_jserv...

Hacer que Apache sirva los Ficheros Estticos del Contexto
El fichero anterior de configuracin de Apache-Tomcat era de alguna forma ineficiente, instruye a Apache a enviar cualquier peticin que empiece con el prefijo /examples para que sea servida por Tomcat. Realmente queremos hacer eso? Hay muchos ficheros estticos que podran ser parte de nuestro contexto servlet (por ejemplo imgenes y HTML esttico), Por qu debera Tomcat servir esos ficheros? Realmente tenemos razones para hacer esto, por ejemplo:
1. Podramos querer configurar Tomcat basndonos en la seguridad para esos recursos.
2. Podramos querer seguir las peticiones de usuarios de recursos estticos usando interceptores.
En general, sin embargo, este no es ese caso; hacer que Tomcat sirva el contenido esttico es slo malgastar CPU. Deberamos hacer que Apache sirviera estos ficheros dinmicos y no Tomcat. Hacer que Apache sirva los ficheros estticos requiere los siguientes pasos:
1. Instruir a Apache para que enve todas la peticiones servlet a Tomcat 2. Instruir a Apache para que enve todas las peticiones JSP a Tomcat.
y dejar que Apache maneje el resto. Echemos un vistazo a un fichero de ejemplo tomcat.conf que hace exactamente esto:
###################################################################### # Apache-Tomcat Smart Context Redirection # ###################################################################### LoadModule jserv_module modules/ApacheModuleJServ.dll <IfModule mod_jserv.c> ApJServManual on ApJServDefaultProtocol ajpv12 ApJServSecretKey DISABLED ApJServMountCopy on ApJServLogLevel notice ApJServDefaultHost localhost ApJServDefaultPort 8007 # # Mounting a single smart context: # # (1) Make Apache know about the context location. Alias /examples c:/jakarta-tomcat/webapps/examples # (2) Optional, customize Apache context service. <Directory "c:/jakarta-tomcat/webapps/examples"> Options Indexes FollowSymLinks # (2a) No directory indexing for the context root. # Options -Indexes # (2b) Set index.jsp to be the directory index file. # DirectoryIndex index.jsp </Directory> # (3) Protect the WEB-INF directory from tampering. <Location /examples/WEB-INF/> AllowOverride None deny from all </Location> # (4) Instructing Apache to send all the .jsp files under the context to the # jserv servlet handler. <LocationMatch /examples/*.jsp> SetHandler jserv-servlet </LocationMatch> # (5) Direct known servlet URLs to Tomcat. ApJServMount /examples/servlet /examples # (6) Optional, direct servlet only contexts to Tomcat.
ApJServMount /servlet /ROOT </IfModule>
Como podemos ver, el inicio de este fichero de configuracin es el mismo que vimos en el ejemplo anterior. Sin embargo, el ltimo paso (montar el contexto), ha sido reemplazado por una larga serie de directivas de configuracin de Apache y ApJServ que ahora explicaremos:
1. Este paso informa a Apache de la localizacin del contexto y los asigna a un directorio virtual de Apache. De esta forma Apache puede servir ficheros de este directorio. 2. Este paso opcional instruye a Apache sobre cmo servir el contexto; por ejemplo podemos decidir si Apache permitir indexar (listar) el directorio o seleccionar un fichero de indice especial. 3. Este paso instruye a Apache para proteger el directorio WEB-INF de los accesos del cliente. Por razones de seguridad es importante evitar que los visitante vean el contenido del directorio WEB-INF, por eemplo web.xml podra proporcionar informacin valiosa a los intrusos. Este paso bloquea el contenido de WEB-INF para los visitiantes. 4. Este paso instruye a Apache para que sirva todas las localizaciones JSP dentro del contexto usando el manejador de servlets jserv. El manejador de servlet redirige estas peticiones basndose en el host y puerto por defecto. 5. Este paso monta las URLs especficas de servelts en Tomcat. Deberamos observar que deberamos tener tantas directivas como el nmero de URLs de servlets especificados. 6. Este ltimo paso es un ejemplo de adicin de un nico contexto servlet a Tomcat.
Es facil ver que este fichero de configuracin es mucho ms complejo y propenso a errores que el primer ejemplo, sin embargo es el precio que debemos pagar (por ahora) para mejorar el rendimiento.
Configurar Varias JVMs Tomcat
Algunas veces es til tener diferentes contextos manejados por diferentes JVMs (Mquinas Virtuales Java), por ejemplo:

Cuando cada contexto sirve a una tarea especfica y diferente y se ejecuta sobre una mquina distinta. Cuando queremos tener varios desarrolladores trabajando en un proceso Tomcat privado pero usando el mismo servidor web
Implementar dichos esquemas donde diferentes contextos son servidos por diferentes JVMs es muy fcil y el siguiente fichero de configuracin lo demuestra:
###################################################################### # Apache-Tomcat with JVM per Context # ###################################################################### LoadModule jserv_module modules/ApacheModuleJServ.dll <IfModule mod_jserv.c> ApJServManual on ApJServDefaultProtocol ajpv12 ApJServSecretKey DISABLED ApJServMountCopy on
ApJServLogLevel notice ApJServDefaultHost localhost ApJServDefaultPort 8007 # Mounting the first context. ApJServMount /joe ajpv12://joe.corp.com:8007/joe # Mounting the second context. ApJServMount /bill ajpv12://bill.corp.com:8007/bill </IfModule>
Como podemoe ver en el ejemplo anterior, usar varias JVMs (incluso aquellas que se ejecutan en diferentes mquinas) puede conseguirse fcilmente usando una URL completa ajp montada. En esta URL completa realmente especificamos el host donde est localizado el proceso Tomcat y su puerto. Si tuvieramos los dos procesos Tomcat ejecutndose en la misma mquina, Deberamos configurar cada uno de ellos con un puerto de conector diferente. Por ejemplo, asumiendo que las dos JVMs se ejecutan sobre localhost, la configuracin ApacheTomcat debera tener algo como esto:
###################################################################### # Apache-Tomcat with Same Machine JVM per Context # ###################################################################### LoadModule jserv_module modules/ApacheModuleJServ.dll <IfModule mod_jserv.c> ApJServManual on ApJServDefaultProtocol ajpv12 ApJServSecretKey DISABLED ApJServMountCopy on ApJServLogLevel notice ApJServDefaultHost localhost ApJServDefaultPort 8007 # Mounting the first context. ApJServMount /joe ajpv12://localhost:8007/joe # Mounting the second context. ApJServMount /bill ajpv12://localhost:8009/bill </IfModule>
Mirando al fichero de arriba podemos ver que tenemos dos puntos de montaje ApJServ explcitos, cada uno apuntando a un puerto diferente de la misma mquina. Esta claro que esta configuracin requiere soporte desde la configuracin encontrada en los ficheros server.xml. Necesitamos diferentes configuraciones de <Connector> en cada fichero para los diferentes procesos Tomcat. Realmente necesitamos dos ficheros server.xml diferentes (llammosles server_joe.xml y server_bill.xml) con diferentes entradas <Connector> como se ve en los siguientes ejemplos:
<?xml version="1.0" encoding="ISO-8859-1"?> <Server> 
<xmlmapper:debug level="0" />  <ContextManager debug="0" workDir="work_joe" >  ...   <Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/> <Parameter name="port" value="8007"/> </Connector>   <Context path="/joe" docBase="webapps/joe" debug="0" reloadable="true" > </Context> </ContextManager> </Server>
Cuando miramos a server_joe.xml podemos ver que el <Connector> est configurado en el puerto 8007. Por otro lado, en server_bill.xml (ver abajo) el conector est configurado para el puerto 8009.
<?xml version="1.0" encoding="ISO-8859-1"?> <Server>  <xmlmapper:debug level="0" />  <ContextManager debug="0" workDir="work_bill" >  ...   <Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/> <Parameter name="port" value="8009"/> </Connector>   <Context path="/bill" docBase="webapps/bill" debug="0" reloadable="true" > </Context> </ContextManager> </Server>
La configuracin del puerto no es la nia diferencia entre los dos ficheros. Tenemos marcas @@@ en los cuatro lugares de los ficheros xml donde hemos realizado cambios. Como podemos ver, esta diferencia es necesaria para evitar que los dos procesos Tomcat sobreescriban los logs y el espacio de trabajo del otro. Entonces deberamos arrancar los dos procesos Tomcat usando el la opcin -f de la lnea de comando:
bin\startup -f conf\server_joe.xml bin\startup -f conf\server_bill.xml
y luego accedemos a ellos desde Apache basndonos en los diferentes prefijos de las URLs del path.
Configurar el Hosting Virtual
Es posible soportar host virtuales sobre Tomcat Ver3.2, de hecho la configuracin de host virtuales es muy similar a la configuracin para mltiples JVM y la razn es sencilla; en Tomcat 3.2 cada host virtual est implementado por un proceso Tomcat diferente. Con la versin actual de Tomcat (Ver3.2), el hosting virtual sin preocupaciones est proporcionado por el servidor web (Apache/Netscape). El soporte de servidor de host virtual es usado por el adaptador Tomcat para redirigir las peticiones a cierto host virtual a la JVM(s) que conteine los contextos de este host virtual. Esto significa que si (por ejemplo) tenemos dos host virtuales (vhost1 y vhost2), tendremos dos JVMs: una ejecutndose en el contexto de vhost1 y la otra ejecutndose en el contexto de vhost2. Estas JVMs no se preocupan de la existencia de la otra, de hecho, no se preocupan del concepto de host virtual. Toda la lgica del hospedaje virtual est dentro del adaptador del servidor web. Para aclarar las cosas, veamos el siguiente fichero de configuracin Apache-Tomcat
###################################################################### # Apache Tomcat Virtual Hosts Sample Configuration # ###################################################################### LoadModule jserv_module modules/ApacheModuleJServ.dll <IfModule mod_jserv.c> ApJServManual on ApJServDefaultProtocol ajpv12 ApJServSecretKey DISABLED ApJServMountCopy on ApJServLogLevel notice ApJServDefaultHost localhost ApJServDefaultPort 8007 # 1 Creating an Apache virtual host configuration NameVirtualHost 9.148.16.139 # 2 Mounting the first virtual host <VirtualHost 9.148.16.139>
ServerName www.vhost1.com ApJServMount /examples ajpv12://localhost:8007/examples </VirtualHost> # 3 Mounting the second virtual host <VirtualHost 9.148.16.139> ServerName www.vhost2.com ApJServMount /examples ajpv12://localhost:8009/examples </VirtualHost> </IfModule>
Como podemos ver, los pasos 1, 2 y 3 definen dos host virtuales en Apache y cada uno de ellos monta el contexto /examples en cierta URL ajpv12. Cada URL ajpv12 apunta a una JVM que contiene el host virtual. La configuracin de las dos JVM es muy similar a la mostrada en la seccin anterior, y tambin necesitaremos usar dos ficheros server.xml diferentes (uno por cada host virtual) y necesitaremos arrancar los procesos Tomcat con la opcin -f de la lnea de comandos. Despus de hacer esto podremos aproximarnos a Apache, cada vez con un nombre de host diferente, y el adaptador nos redirigir la JVM apropiada. La necesidad de mejorar el soporte para hosting virtual Tener cada host virtual implementado por un JVM diferente es un enorme problema de escalabilidad. Las siguientes versiones de Tomcat haran posible soportar varios host virtuales en la misma JVM Tomcat.
Trucos de Configuracin del Mundo Real
Por defecto la distribucin Tomcat viene con una configuracin ingenua cuyo objetivo principal es ayudar al usuario recien experimentado y una operacin "recin salido de la caja"... Sin embargo, esta configuracin no es la mejor forma de desplegar Tomcat en sitios reales. Por ejemplo, los sites reales podran requerir algn ajuste de rendimiento y configuraciones especficas de la site (elementos de path adicionales, por ejemplo). Esta seccin intentar dirigirnos por los primeros pasos que deberamos realizar antes de publicar una site basada en Tomcat.
Modificar y Personalizar los Ficheros Batch
Como mencionamos en las secciones anteriores, los scripts de arrancada estn para nuestra conveniencia. Aunque, algunas veces los scripts que necesitamos para desarrollar deberan ser modificados:

Para configurar los lmites de recursos como el mximo nmero de descriptores. Para aadir nuevas entradas en el CLASSPATH (por ejemplo, drivers JDBC). Para aadir nuevas entradas en el PATH/LD_LIBRARY_PATH (por ejemplo, DLLs de drivers JDBC). Para modificar las selecciones de la lnea de comandos de la JVM. Para asegurarnos de que estmos usando la JVM adecuada (de las dos o tres que podemos tener instaladas en nuestra mquina). Para cambiar el usuario de root a algn otro usuario usando el comando "su" de UNIX.
Por cualquier otra razn.
Algunos de estos cambios se pueden hacer sin cambiar explcitamente los scripts bsicos; por ejemplo, el script tomcat puede usar una variable de entorno llamada TOMCAT_OPTS para seleccionar los parmetros extras de la lnea de comando de la JVM (como configuraciones de memoria, etc). Sobre UNIX tambin podemos crear un fichero llamando ".tomcatrc" en nuestro directorio home y Tomcat tomar la informacin de entorno como PATH, JAVA_HOME, TOMCAT_HOME y CLASSPATH desde este fichero. Sin embargo, sobre NT nos veremos forzados a reescrobor algunos de estos scripts de arrancada... No tengas miedo, slo hazlo!
Modificar las Configuraciones por Defecto de la JVM
Las configuraciones por defecto de la JVM en el script tomcat son muy ingenuas; todo se deja por defecto. Hay algunas cosas que deberamos considerar para mejorar el rendimiento de Tomcat:
1. Modificar la configuracin de memoria de nuestra JVM. Normalmente la JVM asigna un tamao inicial para la pila Java y ya est, si necesitamos ms memoria de est no podremos obtenerla. Adems, en sitios sobrecargados, dar ms memoria a la JVM mejora el rendimiento de Tomcat. Deberamos usar los parmetros de la lnea de comandos como -Xms/Xmx/-ms/-mx para seleccionar los tamaos mnimo y mximo de la pila Java (y chequear si mejora el rendimiento). 2. Modificar nuestra configuracin de threading en la JVM. El JDK 1.2.2 para Linux viene con soporte para threads verdes y nativos. En general, los theads nativos son conocidos por proporcionar mejoras de rendimiento para aplicaciones que tratan con I/O, los threads verdes, por otro lado, ponen menos acento en la mquina. Deberamos experimetnar con estos dos modelos de threads y ver cual es mejor para nuestra site (en general, los threads nativos son mejores). 3. Seleccionamos la mejor JVM para la tarea. Hay distintos vendedores de JVMs por lo que deberemos decidirnos por la ms rpida o la ms barata, segn nos interese
Modificar nuestros Conectores
Los conectores, segn los configura el fichero server.xml de Tomcat, contiene dos Connectors configurados como en el siguiente fragmento:
 <Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/> <Parameter name="port" value="8080"/> </Connector>
 <Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/> <Parameter name="port" value="8007"/> </Connector>
1. Es un conector que escucha en el puerto 8080 para peticiones HTTP entrantes. Este conector es necesario para operaciones independientes. 2. Es un conector que escucha en el puerto 8007 para peticiones AJPV12 entrantes. Este conector es necesario para la integracin del servidor web (integracin de servlets fuera-de-proceso).
El conector AJPV12 es necesario para cerrar Tomcat. Sin embargo, el conector HTTP podra eliminarse si la operacin independiente no lo necesitase.
Usar Almacenes de Threads en nuestros Conectores
Tomcat es un contenedor servlet multi-thread lo que significa que cada peticin necesita ser ejecutada por algn thread. Anteriomente a Tomcat 3.2, por defecto haba que crear un nuevo thread para servir cada peticin que llegaba. Este comportamiento era problemtico en sitios sobrecargados porque:

Arrancar y parar un thread para cada peticin pone en aprietos al sistema operativo y a la JVM. Es dificil limitar el consumo de recursos. Si llegan 300 peticiones de forma concurrente Tomcat abrir 300 threads para servirlas y asignar todos los recursos necesarios para servir las 300 peticiones al mismo tiempo. Esto hace que Tomcat asigne muchos ms recursos (CPU, Memoria, Descriptores...) de lo que debiera y puede bajar el rendimiento e incluso colgarse si los recursos estn exhaustos.
La solucin para estos problemas es usar un thread pool (almacen de threads), que se usa por defecto en Tomcat 3.2. Los contenedores Servlets que usan almacenes de threads se liberan a s mismos de manejar sus treads. En lugar de asignar nuevos threads, cada vez que los necesitan, se los piden al almacen, y cuando todo est hecho, el thread es devuelto al almacen. Ahora el almacen de threads se puede utilizar para implementar tcnicas de control de de threads, como:
1. Mantener threads "abiertos" y reutilizarlos una y otra vez. Esto nos evita el problema asociado con la creacin y destruccin continua de threads. o Normalmente el administrador puede instruir al almacen para que no mantenga demasiados threads desocupados, liberndolos si es necesario. 2. Seleccionando un lmite superior en el nmero de threads usados de forma concurrente. Esto evita el problema de la asignacin de recursos asociada con la asignacin ilimitada de threads. o Si el contenedor alcanza su lmite superior de threads, y llega una nueva peticin, esta nueva peticin tendr que esperar hasta que alguna otra peticin (anterior) termine y libere el thread que est usando.
Podemos refinar las tcnicas descritas arriba de varias formas, pero slo sern refinamientos. La principal contribucin de los almacenes de threads es la reutilizacin de los thrreads un lmite superior que limite el uso de recursos. Usar un almacen de threads en Tomcat es un sencillo movimiento; todo lo que necesitamos hacer es usar un PoolTcpConnector en nuestra configuracin de <Connector>. Por ejejmplo, el siguiente fragmento de server.xml define ajpv12, como un conector con almacen:

SSL Directo
Si queremos que Tomcat sirva directamente HTTP/SSL (https), necesitamos crear un certificado SSL. Para ms informacin sobre SSL y los certificados, te sugiero que eches un vistazo a OpenSSL (Implementacin Open Source SSL) y a mod_ssl (soporte de SSL para Apache).
Verificar el Fichero de Configuracin server.xml de Tomcat
Para usar HTTP con el conector SSL en Tomcat, verificamos que est activado en server.xml:
<Connector className="org.apache.tomcat.service.PoolTcpConnector"> <Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/> <Parameter name="port" value="8443"/> <Parameter name="socketFactory" value="org.apache.tomcat.net.SSLSocketFactory"/> <Parameter name="keystore" value="/var/tomcat/conf/keystore" /> <Parameter name="keypass" value="changeit"/> <Parameter name="clientAuth" value="true"/> </Connector>
En este ejemplo hemos indicado que el keystore es el fichero /var/tomcat/conf/keystore. La password del keystore es changeit y queremos que los clientes se autentifiquen.
Generar un Certificado SSL (RSA) para Tomcat
Lo consegu (al final) con mi IBM JDK 1.3 despus de :

Los jars de jsse deben estar en el CLASSPATH y en $JAVA_HOME/jre/lib/ext (JAVA > 1.2) Desde el documento server.xml. Necesitamos_configurar un certificado de servidor si queremos que esto funcione, y necesitamos JSSE. o Aadimos los jars de JSSE al CLASSPATH o Editamos $JAVA_HOME/jre/lib/security/java.security Aadimos
o security.provider.2=com.sun.net.ssl.internal.ssl.Provider Hacemos: keytool -genkey -alias tomcat -keyalg RSA
RSA es esencial para trabajar con Netscape e IIS. Usamos "changeit" como password (o aadimos atributos de keypass). No necesitamos firmar el
certificado. Podemos configurar los parmetros del keystore y keypass si queremos cambiar el valor por defecto ($HOME/.keystore with changeit) Sugiero que instalemos jcert.jar, jnet.jar y jsse.jar en $JAVA_HOME/jre/lib/ext y luego los aadamos a nuestro CLASSPATH export
CLASSPATH=$JAVA_HOME/jre/lib/ext/jcert.jar:$CLASSPATH export CLASSPATH=$JAVA_HOME/jre/lib/ext/jnet.jar:$CLASSPATH export CLASSPATH=$JAVA_HOME/jre/lib/ext/jsse.jar:$CLASSPATH
Tambin deberamos copiar los ficheros jar en $TOMCAT_HOME/lib/ para que estn bajo el CLASSPATH existente en la arrancada de Tomcat (tomcat.sh). Importar Certificados SSL
Es posible importar certificados con OpenSSL. Aqu estn los pasos necesarios para generar dichos certificados con OpenSSL:

Para generar una nueva peticin y una nueva clave:

openssl req -new -out REQ.pem -keyout KEY.pem
Para generar un certificado x509 auto-firmado desde una peticin de certificado usando una clave suministrada, y ver el texto desde la salida del certificado (que se pondr en el fichero selfSign.pem;
openssl req -x509 -in REQ.pem -key KEY.pem -out CERT.pem
Verificar que la firma es correcta sobre una peticin de certificado:

openssl req -verify -in REQ.pem
Verificar que la firma se hizo usando una clave pblica especificada:

openssl req -verify -in REQ.pem -key KEY.pem
Imprimir el contenido de una peticin de certificado:

openssl req -text -in REQ.pem Importar el CERT en el keystore: keytool -import -v -trustcacerts -alias tomcat -file CERT.pem
Trabajar con el Servicio Jakarta para NT

El servicio NT de Jakarta es un ejecutable que envuelve el contenedor de Servlets Tomcat y lo ejecuta como un servicio NT. Para instalarlo necesitamos:
1. Obtener el ejecutable (jk_nt_service.exe) o Descargar el ejecutable desde el directorio win32/i386 encontrado donde descargamos la Distribucin Binaria de Tomcat. Para aquellos que usan Netscape como navegador, intentar descargar una versin Zip del fichero, si est disponible. Peude haber problemas usando Netscape para descargar ficheros DLL. 2. Personalizar un fichero de propiedades que le proporcione al servicio informacin sobre Tomcat (wrapper.properties). o Localizamos la plantilla del fichero wrapper.properties en nuestro directorio Tomcat. o Modificamos la propiedad wrapper.tomcat_home para que apunte a nuestro home Tomcat o Modificamos la propiedad wrapper.java_home para que apunte a nuestro home Java. 3. Instalar jk_nt_service ejecutndolo con la bandera -i. o Ejecutamos jk_nt_service -I <name of service> <path to
updated wrapper properties> o o o
<name of service> debera ser una sola palabra (sin espacios) como Jakarta <path to updated wrapper properties> debera apuntar a nuestro fichero wrapper.properties (y el servicio comprobar su existencia). Por ejemplo, una lnea de comandos vlida podra ser: jk_nt_service -I
Jakarta wrapper.properties
4. Arrancar Tomcat como un Servicio. o Desde la lnea de comandos, ejecutamos: net start <name of service> (por ejemplo: net start Jakarta) o Desde el applet de servicios de NT, seleccionamos nuestro servicio y pulsamos start Nota: Si la localizacin del fichero log en nuestro fichero wrapper.properties apunta a un directorio que no existe, debemos crearlo antes de arrancar el servicio. 5. Para el servicio Tomcat. o Desde la lnea de comandos, ejecutamos: net stop <name of service> (por ejemplo, net stop Jakarta) o Desde el applet de servicios de NT, seleccionamos nuestro servicio y pulsamos stop
Nota especial: El servicio Tomcat usa AJPV12 para realizar operaciones de limpieza durante su cierre y deberamos asegurarnos de que el conector AJPV12 est definido en nuestro server.xml. En ausencia de un puerto AJPV12 configurado el servicio Tomcat se cerrar abruptamente (es decir ser asesinado) sin hacer ninguna operacin de limpieza
Nota para usuarios del JDK 1.3: Hay un problema conocido en el JDK 1.3 que afecta a las aplicaciones Java que se ejecutan como servicios NT. El bug hace que el servicio termine cuando el usuario actual sale del sistema. La forma ms simple de evitar este problema es usar el JDK 1.2. Si nuestra aplicacin requiere caractersticas del JDK 1.3 podemos echar un vistazo a javaserv o JavaService. Para eliminar el servicio instalado ejecutamos: jk_nt_service -R <name of
service>
Configuracin Avanzada 1. Modificar las propiedades del servicio NT Tomcat. Por defecto el servicio se ejecutar en modo manual bajo la cuenta de usuario del sistema local. Para modificar esto, abrimos el applet de servicios de NT, seleccionamos nuestro servicio y pulsamos startup. Se abrir una ventana que nos permitir personalizar el servicio a nuestro gusto. 2. Modificar el classpath. El classpath est determinado por las propiedades wrapper.class_path, para modificarlo, slo tenemos que aadir/eliminar/modificar lneas wrapper.class_path. El classpath completo se calcula concatenando todas las lneas wrapper.class_path poniendo un ";" entre ellas. 3. Ejecutar varios ejemplares de Tomcat. Digamos que queremos ejecutar un Tomcat para produccin y otro para desarrollo. Todo lo que necesitamos es instalar dos veces el servicio Tomcat pero bajo nombres diferentes (y con diferentes ficheros wrapper.properties y server.xml). o Debemos asegurarnos de que los conectores AJPV12 y HTTP estn modificados en cada server.xml para evitar conflictos. o Debemos asegurarnos de actualizar la propiedad wrapper.shutdown_port en wrapper.properties para que apunte a los puertos AJPV12 corectos (por defecto es 8007). 4. Modificar la lnea de comandos usada para arrancar Tomcat. El servicio Tomcat toma toda la configuracin de su lnea de comandos de wrapper.properties! Para personalizar la lnea de comandos, editamos la propiedad wrapper.cmd_line y nos aseguramos de que es una lnea de comandos Java legal.
Tomcat Dentro del Servidor Web (Windows)

Configruaciones Soportadas
Para la operacin "en-proceso" tendremos que usar los redirectores Netscape/IIS. Debemos mirar a su soporte de configuraciones soportadas. El adaptador en-proceso se ha probado usando JDK 1.1.7b, JDK 1.1.7 de IBM, JDK 1.1.8, JDK 1.2.2., y JDK 1.3.
Instalacin
Como con Tomcat 3.2, hay una versin pre-construida del adapador en-proceso jni_connect.dll, bajo el directorio win32/i386 de donde nos bajamos la distribucin binaria de Tomcat. Para aquellos que usan Netscape como navegador, intentar descargar una versin Zip del fichero, si est disponible. Puede haber problemas usando Netscape para descargar ficheros DLL. El adaptador JNI de Tomcat requiere las siguientes acciones:
1. Poner jni_connect.dll en el directorio bin - jni_connect.dll es usado para realizar llamadas desde Tomcat al servidor web. 2. Actualizar workers.properties y aadimos el worker JNI - El wroker JNI necesita varios tems de configuracin, y necesitaremos aadirlos al fichero de propiedades del worker. 3. Actualizar server.xml - Necesitamos instruir a Tomcat para usar los controladores de conexiones JNI. Tambin necesitaremos proporcionar la propiedad home para nuestro ContextManager (despus crearemos bajo este directorio los ficheros de log y los directorios de trabajo). 4. Direccionar contexto(s) al Tomcat en-proceso - necesitamos instruir al redirecionador para que enve trabajo al Tomcat en--proceso. 5. Re-arrancamos nuestro servidor (para que los cambios tengan efecto) Poner jni_connect.dll bajo el directorio bin
Poenemos jni_connect.dll dentro de <tomcat_home>\bin\win32\i386\.

Actualizar workers.properties y aadir el worker JNI
Deberamos proporcionarle al worker JNI varias configuraciones, algunas son obligatorias y otras son una opcin: Nota: Las siguientes instrucciones asumen que Tomcat est instalado en c:\jakarta-tomcat. Debemos ajustarlas de forma apropiada a nuestro directorio de instalacin.
1. Deberamos definir un worker JNI. Configuramos la propiedad worker.list para que apunte a un worker llamado jni:
worker.list=jni
Anunciamos que el worker llamado jni es del tipo jni: worker.jni.type=jni
2. Deberamos configurar un classpath para usarlo en el Tomcat en-proceso. Para configurar el classpath usamos la propiedad worker.name.class_path,por ejemplo:
3. 4. 5. 6. 7. 8. 9. worker.jni.class_path=c:\jakarta-tomcat\classes worker.jni.class_path=c:\jakarta-tomcat\lib\jaxp.jar worker.jni.class_path=c:\jakarta-tomcat\lib\parser.jar worker.jni.class_path=c:\jakarta-tomcat\lib\jasper.jar worker.jni.class_path=c:\jakarta-tomcat\lib\servlet.jar worker.jni.class_path=c:\jakarta-tomcat\lib\webserver.jar worker.jni.class_path=c:\jdk1.2.2\lib\tools.jar
Nota: No debemos olvidar incluir tools.jar den JDK en nuestro classpath. 10. Deberamos proporcionar un path completo a la implementacin dll de la JVM. Para JDK1.1.x es javai.dll, para JDK1.2.x es jvm.dll. Por ejemplo:
11. worker.jni.jvm_lib=c:\jdk1.2.2\jre\bin\classic\jvm.dll
12. Deberamos proporcionar opciones de la lnea de comandos para tomcat; debemos proporcionar una opcin -config para especificar nuestro server.xml configurado JNI. Por ejemplo:
13. worker.jni.cmd_line=-config 14. worker.jni.cmd_line=c:\jakarta-tomcat\conf\jni_server.xml
Nota: El string cmd_line no soporta espacios embebidos. Si el path al fichero jni_server.xml incluye espacios, debemos usar el nombre DOS 8.3 para los directorios que contienen espacios en sus nombres. 15. Deberamos especificar la localizacin del home de Tomcat como una propiedad del sistema Java. Por ejemplo:
16. worker.jni.sysprops=tomcat.home=c:\jakarta-tomcat
17. Podemos especificar propiedades de sistema Java adicionales. Por ejemplo:

18. worker.jni.sysprops=java.compiler=NONE
19. Podemos especificar ficheros para ser usados por stdout y stderr de la JVM. Por ejemplo:
20. worker.jni.stdout=c:\jakarta-tomcat\logs\jvm.stdout 21. worker.jni.stderr=c:\jakarta-tomcat\logs\jvm.stderr
22. Podemos especificar una PATH adicional, para usarlo cuando se carguen las dlls (til cuando estmos usando cdigo nativo). Por ejemplo:
23. worker.jni.ld_path=c:\SQLLIB\bin 24. worker.jni.ld_path=c:\my\native\code
Podemos encontrar un fichero de ejemplo (jni_workers.properties) bajo el directorio jakarta-tomcat/conf. Los contenidos de este fichero asumen que Tomcat est instalado en c:\jakarta-tomcat.
Actualizar server.xml
Por defecto Tomcat lee el fichero <tomcat_home>\conf\server.xml. Este fichero define entre otras cosas los contextos y conectores usados por Tomcat. Para poder trabajar en-proceso tendremos que realizar las siguientes acciones:
1. Deberamos actualizar la lista de conectores. Eliminar todos los conectores de nuestro server.xml y aadir las siguientes lneas (observa que no necesitamos actualizar el rea marcada con <tomcat_home>)
2. 3. 4. 5.
 <Connector className="org.apache.tomcat.service.JNIEndpointConnector"> 6. <Parameter name="native_lib" 7. value="<tomcat_home>/bin/win32/i386/jni_connect.dll"/> 8. </Connector>
Estas lneas aaden un conector JNI a Tomcat. 9. Deberamos actualizar el atributo home usado por el ContextManager para que sepa donde situar los directorios log, work y webapps. Por ejemplo:
10. <ContextManager debug="0" workDir="work" home="<tomcat_home>" /> 11. . 12. . 13. . 14. </ContextManager />
Podemos encontrar un fichero de ejemplo (jni_server.xml) bajo jakarta-tomcat/conf.

Redirigir Contextos hacia los Workers JNI
Necesitaremos seleccionar los contextos que deseamos servir usando nuestro worker jni. Sobre Netscape podemos hacer esto modificando las lneas en el objeto de configuracin del servlet para que reflejen el trabajo redirigido al nuevo worker JNI. Por ejemplo:
<Object name=servlet> ObjectType fn=force-type type=text/plain Service fn="jk_service" worker="jni" </Object>
Sobre IIS tendremos que modificar nuestro fichero de montaje del worker para montar los contextos del worker JNI. Por ejemplo
/examples/*=jni
Cuando lo hayamos hecho debemos re-arrancar el servidor. Esto es todo, ahora podemos ejecutar Tomcat en-proceso.
Construir el conector dll JNI
El conector JNI fue desarrollado usando Visual C++ Ver.6.0, por eso tener este entorno es un prerrequisito si queremos realizar una construccin personalizada. Tambin necesitaremos una instalacin del JDK (el jre no es suficiente) para usar los ficheros includes del JDK. Los pasos que necesitamos realizar son:
1. Cambiar al directorio del cdigo fuente del conector. 2. Asegurarnos de que la variable de entorno JAVA_HOME apunta a nuestra instalacin del JDK. 3. Ejecutar el siguiente comando:
4. MSDEV jni_connect.dsp /MAKE ALLL
Si msdev no est en nuestro path, debemos introducir el path completo a msdev.exe.
Esto construye tanto la versin liberada como de depuracin del conector JNI. Una alternativa sera abrir el fichero de espacio de trabajo (jni_connect.dsw) en msdev y construirlo usando el men build.
Cmo funciona esto?
Tabajar "en-proceso" requiere tanto el servidor redireccionador (IIS-Tomcat/NetscapeTomcat) como el conector en-proceso. El servidor puede dirigir el trabajo a diferentes workers basndose en sus nombres; ahora que hemos creado el worker JNI el servidor redireccionador puede reenviarle trabajo... La operacin bsica es:
1. Durante la inicializacin el servidor redireccionador arrancar el worker JNI 2. Despus de la arrancada el worker JNI crea una JVM dentro del servidor web y arranca Tomcat en ella. 3. Por cada peticin entrante para un servlet, el servidor chequear qu worker es responsable del contexto especfico. Si este worker es el worker JNI se le asigna la peticin. 4. El worker JNI adjunta a la JVM y enva la peticin dentro del motor Tomcat (usando el JNIEndpointConnector). Entonces Tomcat ejecutar la peticin. 5. El servidor recoge la respuesta desde el worker JNI y se la devuelve al navegador.

Tomcat

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tomcat

Transféré par

Droits d'auteur :

Formats disponibles

Tomcat - Introduccin

Autor: Apache Traductor: Juan Antonio Palos (Ozito)

Introduccin al Servidor de Aplicaciones Tomcat de Apache

Cmo Instalar la Versin Binaria de Tomcat?

Muy sencillo. Deberamos:

3. Sobre UNIX deberamos teclear: para bash/sh:

Para parar Tomcat ejecutamos:

La Estructura de Directorios de Tomcat

doc lib logs

Adicionalmente podemos, o Tomcat crear, los siguientes directorios:

Los Scripts de Tomcat

Restaura las configuraciones de TOMCAT_HOME y CLASSPATH grabadas prviamente.

Ficheros de Configuracin de Tomcat

La configuracin de Tomcat se basa en dos ficheros:

es el fichero de configuracin principal de Tomcat. Sirve para dos

Los elementos ms importantes de server.xml se describen en la siguiente tabla:

Se puede encontrar informacin adicional dentro del fichero server.xml.

Si la propiedad ContextManager.home de server.xml es relativa, ser relativa al directorio de trabajo actual.

Configurar Tomcat para Cooperar con Apache Web Server

Cul es la Configuracin Necesaria

Veamos ahora un simple fichero tomcat.conf:

Esto es todo!, ya hemos construido mod_jserv...

ApJServMount /servlet /ROOT </IfModule>

Por cualquier otra razn.

Modificar nuestros Conectores

Como se puede ver el almacen tiene 3 parmetros de configuracin:

Usar el SecurityManager de Java con tomcat

Los Workers Tomcat

Configurar Propiedades del Worker

Propiedades de un Wroker ajp13

El puerto donde el worker Tomcat escucha peticiones ajp12.

worker.loadbalancer.balanced_workers= local13, local12

worker.localjni.cmd_line=-config worker.localjni.cmd_line=path-totomcats-server.xml-file worker.localjni.cmd_line=-home worker.localjni.cmd_line=-pathto-tomcat-home

worker.localjni.stdout=full-pathto-stdout-file worker.localjni.stderr=full-pathto-stderr-file worker.localjni.sysprops=someproperty

Path a las libreras dinmicas worker.localjni.ld_path=someadicionales (similar en naturaleza extra-dynamic-library-path a LD_LIBRARY_PATH).

Macros en Ficheros de Propiedades

Terminar con los siguientes valores para las propiedades worker.inprocess.class_path:

- tiene que apuntar a nuestro tomcat_home.

- tiene que apuntar a donde tengamos situado el JDK.

- tiene que apuntar al separador de ficheros de nuestro sistema operativo.

Cuando hagamos esto, el worker jni por defecto, debera funcionar.

JkExtractSSL JkHTTPSIndicator JkSESSIONIndicator JkCIPHERIndicator JkCERTSIndicator

La redireccin JK podra configurarse en host virtuales:

Lo consegu (al final) con mi IBM JDK 1.3 despus de :

Para generar una nueva peticin y una nueva clave:

Verificar que la firma es correcta sobre una peticin de certificado:

Verificar que la firma se hizo usando una clave pblica especificada:

Imprimir el contenido de una peticin de certificado:

Trabajar con el Servicio Jakarta para NT

Tomcat Dentro del Servidor Web (Windows)

Poenemos jni_connect.dll dentro de <tomcat_home>\bin\win32\i386\.

Anunciamos que el worker llamado jni es del tipo jni: worker.jni.type=jni

17. Podemos especificar propiedades de sistema Java adicionales. Por ejemplo:

Podemos encontrar un fichero de ejemplo (jni_server.xml) bajo jakarta-tomcat/conf.

Si msdev no est en nuestro path, debemos introducir el path completo a msdev.exe.

Vous aimerez peut-être aussi