log4j 1.2.15

 

Normalmente en mis proyectos maven añado el log4j, siempre la versión 1.2.12. No por ningún motivo en particular. Símplemente era la versión disponible la primera vez que lo añadí a un proyecto maven y luego ha prevalecido el copy-paste de esa dependencia de un proyecto a otro.

El otro día cree un proyecto en casa y no tenía ningún sitio de donde copiar esta dependencia, así que me fuí a internet y busqué cómo ponerla. Puse la 1.2.15, que es la última que encontré disponible para maven.

Me pongo a compilar con maven, a generar el proyecto para eclipse y … ¡¡ Sorpresa !!. Da fallo. Busco el motivo y resulta que entre los jar que no puede bajarse, está el javamail, el activation.jar y algún otro más de los de SUN. Efectivamente, SUN no permite distribuir sus jar, por lo que oficialmente no se puede hacer. En los repositorios maven que hay por el mundo, no están estos jar de SUN, así que maven no se los puede bajar. Hay que bajárselos a mano y ponerlos en tu repositorio local de maven.

Y digo yo… ¿necesito javamail para log4j? Y aunque sea así, ¿voy a usarlo?. Pues más bien no. No tengo ningún interes en recibir por correo el log de mi aplicación y tampoco tengo ningún enemigo al que odie lo bastante como para mandárselo. Mejor dicho, sí lo tengo, pero lo que no tengo son ganas de quedarme de patitas en la calle.

Creo que esta vez se han pasado un poco. Entiendo que un momento dado, ante un error crítico, alguna aplicación crítica quiera enviar un correo a alguien. Pero, ¿es con un log.error(…) la mejor forma de hacerlo?. Desde luego puede ser cómoda en vez de usar javamail directamente, pero ¿tienen que cargar todas las aplicaciones que quieran un uso normal de log4j cargar con javamail?. A mi, desde luego, no me gusta.

Y aquí es donde llegamos a un punto donde siempre he tenido mis dudas. Por un lado la lógica y la elegancia me dicen que debería hacerse algo como log4j-core.jar con lo básico de log4j, es decir, sacar los log por pantalla o por fichero y poco más. Luego, deberían hacerse otros jar de amplicación, como log4j-mail.jar, log4j-bd.jar, etc, de forma que cada uno cargue sólo con lo que necesita. Sin embargo, la pereza me pediría que hubiera un único log4j-con-todo.jar y despreocuparme de andar buscando los que debo. Si me sobra el 90% del jar, da igual, no pasa nada.

Y esas dudas son las que siempre me corroen en el trabajo. Ante un proyecto gigante… ¿hacemos muchos jar pequeñitos por temas, de forma que en otros proyectos podamos llevarnos aquellos mini-jar que necesitamos? o por el contrario ¿hacemos un mega jar con todo y si un proyecto no necesita parte de él no pasa nada?

En la primera opción, al empezar un proyecto, debemos empezar a elegir jars que necesitamos y a coger también los jar de los que dependen esos jar. Afortunadamente maven nos ayuda en el proceso. Sin embargo, la segunda opción es menos elegante pero infinitamente más cómoda. Cuando empiezo el proyecto, me copio el mega-jar-que-lo-tiene-todo y a trabajar, sin más complicaciones.

¿Tú qué eliges?. ¿Elegancia o pereza?

Esta entrada ha sido publicada en log4j, maven y etiquetada como , , . Guarda el enlace permanente.

3 respuestas a log4j 1.2.15

  1. Lek dijo:

    Jé, esto me ha recordado a nosotros. Creo que todos los que usamos maven acabamos teniendo el mismo problema. La solución (que debería ser más sencilla) son las exclusiones. Copio y pego de un pom que tengo por aquí (a ver si se ve bien):
    <dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.15</version>
    <exclusions>
    <exclusion>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    </exclusion>
    <exclusion>
    <groupId>javax.mail</groupId>
    <artifactId>mail</artifactId>
    </exclusion>
    <exclusion>
    <groupId>com.sun.jmx</groupId>
    <artifactId>jmxri</artifactId>
    </exclusion>
    <exclusion>
    <groupId>com.sun.jdmk</groupId>
    <artifactId>jmxtools</artifactId>
    </exclusion>
    </exclusions>
    </dependency>

  2. Lek dijo:

    Pues más o menos se ve, aunque sin «espaciar» 😉

    Y respecto a las preguntas, que me las dejaba en el tintero, a medida que un proyecto crece creo que lo mejor es ir modulándolo. A la larga te ahorras un montón de trabajo repetido.

  3. Manu dijo:

    Hola, hace unos días encontré tu web buscando información acerca de un error en el pom.xml y resulta que tenía que ver con ésto que comentas aquí sobre log4j 1.2.15 y las dependencias a JARs de Sun.

    Bien pues usé la solución que aportaba Locke y funcionó.

    Días despues me pasó algo similar con hibernate y una dependencia al jta.jar de Sun. ésta vez «googleando» encontré otra solución y que tb se podría haber usado en el caso de log4j 1.2.15 imagino.

    Se trata de bajarse de Sun las clases de la dependencia en cuestión y luego instalarlas desde maven. Os pongo unos links a la web de maven para quien alguien como yo andara pedido en el tema le sirva de ayuda.

    La problemática en sí y como solucionarlo: http://maven.apache.org/maven-1.x/reference/standard-sun-jar-names.html

    Cómo instalar un JAR de terceros: http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html

    Espero que os sirva de ayuda

    Un saludo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.