Noticias Weblogs Foros Wiki Código

Meta-Info

¿Que es?

Planeta Código es un agregador de weblogs sobre programación y desarrollo en castellano. Si eres lector te permite seguirlos de modo cómodo en esta misma página o mediante el fichero de subscripción.

rss subscripción

Sponsors

Puedes utilizar las siguientes imagenes para enlazar PlanetaCodigo:
planetacodigo

planetacodigo

Si tienes un weblog de programación y quieres ser añadido aquí, envíame un email solicitándolo.

Idea: Juanjo Navarro

Diseño: Albin

Cuaderno de software

Ficheros .war sin las librerías del proyecto con maven y Tomcat

Octubre 24th, 2011 - [Enlace local]

Uno de los problemas que nos encontramos al trabajar con ficheros .war es el rápido crecimiento en volumen de estos en el momento en el que incluimos frameworks tipo Spring o Hibernate. Este problema da lugar a que al hacer pases a producción estemos subiendo un % de código que no cambia que resulta muy poco efectivo, aparte de que si tenemos 5 productos que utilizan el mismo framework lo estamos subiendo 5 veces.

Para resolver este problema hay que atacar desde dos lados.

Primero, construir los .war sin las librerías, en nuestro caso y utilizando maven fué suficiente con definir el scope de cada dependencia como provided. Para ahorrarnos quebraderos de cabeza en los desarrolladores con el manejo de librerías lo que hemos hecho ha sido crear dos ficheros pom, uno que construye durante la etapa de desarrollo y otro (el que tiene las dependencias marcadas como provided) que utilizamos para construir cuando queremos generar un paquete que irá a producción.

Segundo, configurar Tomcat (en nuestro caso versión 6.0.29), se tratará de crear un directorio en el que se alojarán aquellas librerías que serán compartidas por nuestras aplicaciones. Nuestra solución pasó por crear un directorio llamado shared/lib en $CATALINA_HOME (normalmente directorio en el que están los ficheros de Tomcat) en el que alojamos dichas librerías. Para que Tomcat lo utilice deberemos configurar en el fichero conf/catalina.properties la variable shared.loader para que lea el contenido de dicha carpeta de librerías:

shared.loader=${catalina.home}/shared/lib,${catalina.home}/shared/lib/*.jar

Evidentemente queda en nuestra mano encontrar el mejor modo de mantener correctamente el contenido de las librerías compartidas.

Si por h o por b quisieramos mantener librerías en un proyecto que no se compartiesen no habría ningún problema en mantener el scope como compile y esa librería viajaría empaquetada en el .war del proyecto y solo sería utilizable por este.

 

Nota I: Siguiendo la documentación de Tomcat parece ser que ciertas librerias como los jdbc no deberían alojarse en la carpeta shared sinó en la carpeta lib del propio tomcat, son casos muy excepcionales y con el que, por ahora, no nos hemos encontrado.

Nota II: Nuestro proyecto utilizaba la librería el-api.jar que viene por defecto en el directorio lib de Tomcat, el problema surgió en las versiones 2.1 para Tomcat y 2.2 para nuestra aplicación, lo resolvimos borrando la librería el-api.jar de Tomcat y creando un enlace a la librería 2.2 que utilizamos en nuestra aplicación, no ha habido ningún problema de funcionamiento por ahora. El problema surje porque la librería no tiene el número de versión incluido en el nombre.


» Leer más, comentarios, etc...

Información legal y técnica