2009/2/10 Jose San Leandro
<jose.sanleandro@xxxxxxxxxxxx>
Hola,
Nosotros también evaluamos cambiar a SLF4J hace un tiempo, aunque no
terminamos de (empezar a) hacer la migración.
En mi opinión, lo peor de Commons-Logging es que no acabas percibiendo
el valor que presupone la librería. Commons-Logging surgió para lidiar
con la amenaza que suponía el nuevo API del JDK para logging, que al
final resultó (al menos en lo que yo he visto) no ser tal competidor
frente a Log4J. Y a cambio de esa promesa, te obliga a sufrir pequeños
contratiempos esporádicos del tipo
"org.apache.commons.logging.impl.Log4jFactory does not implement
LogFactory", o incluso los temidos "NoClassDefFoundException".
Nosotros tenemos comentada la linea típica de:
-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory
y vamos descomentándola y volviéndola a comentar según aparecen los
problemas. Al final, no llegas a nada en claro. Sólo quieres no perder
tiempo en eso. Ya es bastante 'tricky' a veces Log4J como para hacerlo
todo más lioso.
Aparte de eso, el 'Parameterized Logging' aparentemente no tiene más
que ventajas: simplifica, no pierde el tiempo construyendo el mensaje
si no va a imprimirlo... Pero deja vía libre a que se haga mal uso
inadvertidamente.
Por ejemplo, al migrar a SLF4J un código como éste:
if (logger.isInfoEnabled()) {
logger.info("User " + user.getUserId() + " has posted " +
dao.findMessagesByUser(user.getUserId()).size() + " messages in "
+ (dateFormatter.format(new Date() - user.getRegistrationDate())) + "
days.");
}
Resultando si se hace tal cual en:
logger.info("User {} has posted {} messages in {} days.",
new Object[] {
new Long(user.getUserId()),
new Long(dao.findMessagesByUser(user.getUserId()).size()),
new Integer(dateFormatter.format(new Date() -
user.getRegistrationDate()))
});
Con lo que incurriríamos en un peor rendimiento si INFO no está
habilitado para ese logger, que con el 'if'. Aparte, el 'if' tampoco lo
hace más complicado, pero sí más incómodo.
Que conste que aunque uno se hace mayor y tal, y ya no soy tan
activista en contra del logging, sigue gustándome más un código sin
logging que con él. Si pones debug y lo dejas y llega a producción, es
una 'guarrería'. Si te sirvió para arreglar algo, perfecto, pero una
vez arreglado quítalo. El compilador debería hacer incompatible la
optimización con los 'logger.debug()".
BTW, ¿qué fue de orange :) ?
On Tue, 10 Feb 2009 18:32:02 +0100 Rafael Luque Leiva
<rafael.luque@xxxxxxxx> wrote:
>
> Hola,
>
> En nuestro último proyecto, que estamos a punto de poner en
> producción, hemos decidido migrar a SLF4J (Simple Logging Facade for
> Java) [1], un proyecto detrás del cuál está Ceki Gülcü, creador de
> Log4J.
>
> Conceptualmente el proyecto es similar a Jakarta Commons Logging
> (JCL) [2]; es decir, proporciona a las aplicaciones un API fachada de
> logging, que permite reemplazar la implementación de logging
> subyacente (Log4J, JDK 1.4, Logback, etc.) sin tener que recompilar la
> aplicación. Esto es especialmente útil para desarrolladores de
> librerías o frameworks, que de este modo, no imponen al usuario final
> ninguna dependencia de una implementación concreta.
>
> La diferencia entre ambos frameworks radica en su implementación,
> siendo la de SLF4J mucho más sencilla (y también robusta). A
> diferencia de JCL, la asociación con la implementación finalmente
> empleada se realiza estáticamente (en tiempo de despliegue)
> evitándonos los frecuentes problemas con classloaders que plantea
> commons-logging. Por ejemplo, para usar Log4J como backend, basta
> añadir el adaptador slf4j-log4j12.jar (y por supuesto
> log4j-1.2.x.jar) al classpath de la aplicación.
>
> Además de resolver los quebraderos de cabeza habituales de JCL, aporta
> otras características interesantes como:
>
> * Parametrized Logging: Estamos acostumbrados a evitar el coste de
> generación de los mensajes de traza cuando está desactivada
> mediante expresiones de comprobación del tipo:
>
> Logger logger = ...
>
> if (logger.isInfoEnabled()) {
> logger.info("Thread name: " + name);
> }
>
> Mediante los mensajes parametrizados de SLF4J esta expresión se
> puede reemplazar por esta otra, mucho más simple:
>
> logger.info("Thread name: {}", name);
>
>
> * Puente entre APIs de logging: Además de usar directamente el
> SLF4J API, también es posible usarlo como puente entre diferentes
> implementaciones. Existen implementaciones de JCL over SLF4J o
> Log4J over SLF4J, de modo que las aplicaciones existentes se
> pueden migrar fácilmente.
>
> Los que useis Maven2 os encontrareis con la tediosa tarea de
> excluir las dependencias transitivas de commons-logging de cada
> librería que la utilice. En este punto nos ha resultado de gran
> utilidad "Version 99 Does Not Exist" [3], un simple pero genial idea
> de Erik Van Ooesten, consistente en un repositorio Maven 2 que sirve
> JARs vacíos (y sus correspondientes poms y metadatos) de cualquier
> paquete con el número de versión 99.0-does-not-exist.
>
> De esta manera, para eliminar cualquier rastro de commons-logging de
> un proyecto basado en Maven2, basta con añadir la dependencia:
>
> <dependency>
> <groupId>commons-logging</groupId>
> <artifactId>commons-logging</artifactId>
> <version>99.0-does-not-exist</version>
> </dependency>
>
>
> Espero que a alguien le pueda ser de utilidad.
>
> Un saludo,
> Rafa
>
>
> [1] SLF4J: http://www.slf4j.org/
> [2] JCL: http://commons.apache.org/logging/
> [3] Version99 Does Not Exist:
> http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html
>
>
---------------------------------------------------------------------
Permalink: http://www.orange-soft.com/mindfood/archive/msg00308.html
Enviar a delicious: http://www.orange-soft.com/postdelicious?msg=308
Para eliminar tu suscripción, mail a: mindfood-unsubscribe@xxxxxxxxxxxxxxx
Para ver comandos adicionales, mail a: mindfood-help@xxxxxxxxxxxxxxx