Re: [mindfood] Uso de Commons Logging

[Jose San Leandro <jose.sanleandro@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 19 April 2004 18:29, Rafael Luque Leiva wrote:
> 
> Hola a todos,
> 
> En nuestro último proyecto J2EE, hemos decidido no emplear Commons
> Logging API como teníamos previsto inicialmente, sino invocar
> directamente el correspondiente framework de logging (en nuestro caso
> log4j).
> 
> Commons Logging es un proyecto de Jakarta que permite descubrir en
> tiempo de ejecución el framework de logging disponible en el classpath y
> utilizarlo. Se emplea con frecuencia por los desarrolladores de
> librerías y frameworks (p.ej. Digester y Struts utilizan
> commons-logging) para no imponer al usuario final de la librería el uso
> de una implementación concreta de logging. Es el usuario quien determina
> qué producto de logging utilizará la librería.
> 
> A pesar de este aparente valor añadido y de su uso muy extendido, le
> encontramos bastantes inconvenientes:
> 
> - Introduce una complejidad que en la mayoría de proyectos no está
> justificada. Desde el punto de vista de las metodologías ágiles, el
> diseño inicial no debe contemplar requisitos o necesidades futuras, que
> deben abordarse sólo cuando verdaderamente se planteen.

No estoy seguro de haberte interpretado correctamente. ¿En qué sentido 
introduce complejidad? ¿A nivel de API, gestión de configuración,...?

> - Log4j y JDK 1.4 Logging tienen un patrón de uso casi idéntico, con lo
> que para conmutar entre uno y otro basta con hacer una sencilla
> sustitución en el código fuente.
> 
> - Como se trata de abstraer la funcionalidad de diferentes productos,
> Commons Logging sólo puede ofrecer el mínimo común denominador de los
> diversos frameworks que soporta. Por ejemplo, no dispone de los NDC de
> log4j.

Eso está claro. Es el inconveniente intrínseco de abstraer la implementación.

> - Todo wrapper supone una cierta sobrecarga desde el punto de vista del
> rendimiento.

Bueno, eso puede no ser cierto en todos los casos. Por ejemplo, mediante 
preprocesadores, o, en Java, implementaciones del patrón Null Object. Este 
patrón puede permitir aprovechar la optimización del árbol AST por parte del 
compilador, eliminando las ramas que terminen en sentencias vacías. Aunque 
lamentablemente no todos los compiladores lo soportan.
Para eliminar esta sobrecarga, a nivel de bytecode, existe al menos una 
herramienta, Just4Log [1], que además es integrable en Ant.

> Nuestra conclusión es que commons-logging sólo es útil cuando proteger
> nuestro código frente a cambios en el sistema de logging se encuentre
> realmente entre los requisitos del proyecto. En caso contrario, su uso
> indiscriminado más que fomentar un diseño flexible y elegante, nos
> parece que complica innecesariamente.

En general, ni el logging ni el sistema utilizado para tal fin debería, en la 
mayoría de las ocasiones, formar parte de los requisitos de ningún proyecto.
Deduzco que hablas por experiencia, y frente a eso no se puede argumentar 
nada :).
Yo siempre uso Commons-Logging. Aunque en teoría la razón es la independencia, 
tengo que decir que nunca he sacado partido a esta flexibilidad.
Lo que sí he padecido han sido los efectos de configuración errónea de Log4J, 
como por ejemplo mensajes de log duplicados, aparición de mensajes de una 
categoría en appenders que no la tienen definida, y errores a primera vista 
inescrutables :).

> 
> Nos gustaría conocer vuestra opinión y qué uso hacéis de este o de otros
> wrappers con filosofía semejante.
Yo desarrollé el equivalente a Commons-Logging para intérpretes de expresiones 
regulares [2], razón por la cual no te voy a dar la razón :D.

> Un saludo,
> 
> --
> Rafael Luque, rafael.luque@xxxxxxxxxxxxxxx
> Orange Software
> 

Un saludo,
Jose

[1] <http://just4log.sourceforge.net/>
[2] <http://regexpplugin.sourceforge.net/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAhOHMCAvt6RF8M0cRAuz3AJ9Bi7GO2S5xV3rsxIU+yC5SFkuT9ACdHXXr
mbSKyyAqDlJKD+tVHekct2g=
=tccz
-----END PGP SIGNATURE-----