KEMBAR78
Blog de Iván López: Tomcat
Mostrando entradas con la etiqueta Tomcat. Mostrar todas las entradas
Mostrando entradas con la etiqueta Tomcat. Mostrar todas las entradas

jueves, 4 de junio de 2009

Configurar la página por defecto de Tomcat y de una aplicación web

   Cuando instalamos tomcat y lo arrancamos sin cambiar la configuración por defecto, la página principal que vemos cuando nos conectamos a http://localhost:8080 es la típica que muestra que el servidor se ha configurado correctamente:
If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations!


   Para nuestras pruebas en casa no hay problema en escribir una url como http://localhost:8080/Mufly-0.2.1/MuflyMain.html, que es justamente la url principal de Mufly, pero si queremos darle un aspecto más profesional y amigable para el usuario hay que evitar el tener que teclear todo eso. Para ello debemos configurar dos opciones.

Cambiar la página inicial del tomcat para que cargue un contexto determinado
   La respuesta la tenemos en las FAQ de Tomcat aunque un poco escondida. Ahí nos indican que en $TOMCAT_HOME/etc/web.xml se encuentra una lista con los archivos que cargará el servidor en caso de que existan y el orden en que lo hará.
El primer paso por tanto es renombrar o eliminar los archivos index.html, index.htm e index.jpg. Y posteriormente crear un archivo estático index.html con el contenido que nos indican, en mi caso sería:
<html>
<head>
<meta http-equiv="refresh" content="0;URL=Mufly-0.2.1/">
</head>
<body>
</body>
</html>
   Con esto conseguimos que escribiendo en el navegador la url http://localhost:8080, el servidor Tomcat nos redireccione automáticamente a http://localhost:8080/Mufly-0.2.1/. Pero aún así no es suficiente.

Definir la página por defecto de un contexto
   Cuando se carga un contexto tenemos que indicar explícitamente la página que queremos cargar. En la mayoría de las ocasiones el usuario no la conoce, y tampoco tiene que hacerlo. La solución pasa por configurar en el archivo web.xml del contexto la página por defecto. En mi caso el archivo es $TOMCAT_HOME/webapps/Mufly-0.2.1/WEB-INF/web.xml y simplemente he añadido lo siguiente:
<welcome-file-list>
<welcome-file>MuflyMain.html</welcome-file>
</welcome-file-list>

   En teoría con esto ya está configurado, simplemente reiniciamos el servidor y debería funcionar pero en mi caso no funcionaba. Las redirecciones o no funcionaban bien o no cargaban la página que yo quería. Me acordé de cuando trabajaba con tomcat hace un par de años, que cada vez que subíamos un .war o hacíamos algún cambio similar había que borrar el directorio de trabajo porque sino los archivos no se desplegaban correctamente ni se leían los cambios. Así que dicho y hecho:
ivan@doraemon:~/apache-tomcat-6.0.18/bin$ ./catalina.sh stop
Using CATALINA_BASE: /home/ivan/apache-tomcat-6.0.18
Using CATALINA_HOME: /home/ivan/apache-tomcat-6.0.18
Using CATALINA_TMPDIR: /home/ivan/apache-tomcat-6.0.18/temp
Using JRE_HOME: /usr

ivan@doraemon:~/apache-tomcat-6.0.18/bin$ cd ..
ivan@doraemon:~/apache-tomcat-6.0.18$ cd work
ivan@doraemon:~/apache-tomcat-6.0.18/work$ rm -rf *
ivan@doraemon:~/apache-tomcat-6.0.18/work$ cd ..

ivan@doraemon:~/apache-tomcat-6.0.18$ cd bin
ivan@doraemon:~/apache-tomcat-6.0.18/bin$ ./catalina.sh start
Using CATALINA_BASE: /home/ivan/apache-tomcat-6.0.18
Using CATALINA_HOME: /home/ivan/apache-tomcat-6.0.18
Using CATALINA_TMPDIR: /home/ivan/apache-tomcat-6.0.18/temp
Using JRE_HOME: /usr
   Y ahora ya sí, simplemente poniendo en la url del navegador http://localhost:8080 llegamos a la página principal de la aplicación.

martes, 25 de julio de 2006

IP de clientes conectados a Tomcat

   Siguiendo con el artículo de Apache + Tomcat vamos a avanzar un poco más en la migración a la nueva arquitectura. La mayoría de los sistemas ya están migrados, pero aún quedan algunos, y viendo los logs de los tomcats, hay peticiones que no sabemos quién las está realizando.
   En el log del tomcat (al contrario que en Apache) no se queda almacenada la IP del cliente que realiza la petición, por lo que no podemos saber cuál es el sistema que la origina. En producción, obviamente, no podemos montar la solución de validación de Apache + Tomcat puesto que hay cuatro tomcats con un balanceador por delante y sería más complicado. Así, ayer estuve buscando cómo volcar en el log del tomcat la dirección ip de los clientes que realizan las operaciones. En este caso la solución es muy sencilla. Basta con añadir al archivo server.xml lo siguiente:

<Valve className="org.apache.catalina.valves.AccessLogValve"
  directory="logs"  prefix="localhost_access_log."
  suffix=".txt "pattern="common" resolveHosts="false"/>


 Ahora, reiniciamos el tomcat, nos vamos al directorio logs, veremos creado el archivo nuevo de logs, y listo...

172.24.88.172 - "POST ..."
172.24.86.11 - "GET /dispatcher..."

   Intentaremos hacer este cambio en producción la semana que viene. Además nos va a servir para perseguir el origen de unas peticiones que no sabemos muy bien de donde vienen.

viernes, 7 de julio de 2006

Apache + Tomcat + Redirección + Ocultamiento de puertos

   En el trabajo tenemos una arquitectura un tanto particular para comunicar los sistemas entre sí. En lugar de que se llamen unos a otros de manera incontrolada, todos tienen que utilizar un middleware comun llamado dispatcher que, en función de un parámetro que es el código de la operación que se quiere realizar, llama al sistema apropiado pasándole los parámetros necesarios. Ocurre que este dispatcher es una "simple" aplicación web corriendo en un tomcat y se está migrando a una nueva plataforma. Antes de esta migración definitiva lo que está montado es que el dispatcher reenvía todas las operaciones a la nueva plataforma, ésta se comunica con el sistema final, reenvía la respuesta al dispatcher y éste finalmente responde.

   En el entorno de validación, que es el que nosotros administramos, para ir acostumbrando a la gente a utilizar la nueva arquitectura hemos decidido capar diversas operaciones (si no les funcionan van a tener que migrar forzosamente) de una forma elegante y transparente para desarrollo. Vamos a montar un apache "delante" del tomcat, levantado en su mismo puerto que redirija todas las peticiones al tomcat, que estará levantado en otro puerto. Además, en el apache caparemos diversas operaciones para mostrar un mensaje de error y cuando se realice la redirección de las operaciones correctas, mantendremos el puerto del tomcat oculto.

Configuración en Apache
Hemos utilizado la versión 1.3.26 de Apache y el sistema operativo en el que corre es Solaris 8.
En el archivo httpd.conf hemos añadido las siguientes líneas.

Conector de Tomcat:
LoadModule jk_module libexec/mod_jk.so
AddModule mod_jk.c


Definición de las operaciones que queremos capar:
RewriteEngine on
RewriteLog "logs/rewrite_log"
RewriteLogLevel 2
Options +FollowSymLinks
RewriteCond %{THE_REQUEST} .*OPERACION_01.* [OR]
RewriteCond %{THE_REQUEST} .*OPERACION_02.* [OR]
...
RewriteCond %{THE_REQUEST} .*OPERACION_N.* [OR]
RewriteRule dispatcher /error_dispatcher.xml [PT]


Redirección al tomcat:
JkWorkersFile /ruta/del/apache/conf/workers.properties
JkLogFile /ruta/del/apache/logs/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"
JkMount /* worker1

Creamos el worker.properties:
# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=IP_DE_LA_MAQUINA
worker.worker1.port=8009
worker.worker1.lbfactor=50
worker.worker1.cachesize=10
worker.worker1.cache_timeout=600
worker.worker1.socket_keepalive=1
worker.worker1.recycle_timeout=300


   Y listo. Reiniciamos el tomcat y el apache y haciendo una prueba vemos que las operaciones "prohibidas" se redirigen al mensaje de error definido y el resto se resuelven por el tomcat.