Log4j no será el más eficiente pero es muy útil

Casi al finalizar el día de trabajo se presento una pregunta muy peculiar entre uno de mis compañeros de trabajo esta era sobre el uso del log4j en una aplicación. Para comentar un poco los hechos esto fue lo que realmente paso:

1. Me encontraba muy tranquilamente esperando a que el SuSE 10 en una máquina virtual y vi a un compañero programar unas cuantas lineas usando el system.out.println(), cuando lo revise le dije que seria mejor que use el logger para que pueda revisar lo que imprime su aplicación al momento de arrojar errores.
2. Lo siguiente fue una duda por como configurar esto a lo cual simplemente el dije que habia que agregar un nuevo appender (org.apache.log4j.ConsoleAppender) que se encargara de imprimir en la consola, una vez realizado esto procedimos cambiar el código para que utilizara el logger en modo ERROR ya que se pintaba un Exception (en este caso un java.lang.NullPointerException).
3. Luego de mostrarle algunos tips para utilizar el logger (el clasico logger.isDebugEnable y logger.isInfoEnable) le dije que utilizar el system.out.println() era para "Salvajes" haciendo referencia a que esa era una practica muy antigua (casi de la época de las cavernas).
4. Seguido de esto otra persona me dijo por que decía eso de utilizar el sysout ya que ambos cumplían con el mismo objetivo y que le parecía mas fácil el uso del sysout. Mi respuesta fue como diría un amigo "muy hábil" puesto que en ese momento se me ocurrió decir que era por una cuestión de performance.
5. Si esta persona se sentó creyendo que esta era una respuesta adecuada (al menos eso parecía) no tarde en darme cuenta de la tremenda tontería que había dicho (por lo cual pido las disculpas del caso) ya que la verdad es que al ser log4j un framework este agrega un determinado tiempo de llamada a los métodos para el pintado en un archivo, consola, etc y el formateo de los mismos dependiendo del patrón que estemos escogiendo. Todo este tiempo claro esta no es generado por el sysout y por ende a este lo hace "mas veloz" si se trata de escribir claro esta en el sysout.

Por un momento esto nos lleva a pensar cuales podrían ser los motivos que nos llevan a usar un framework para el manejo de logs y si realmente valen la pena usarlos ya que tendríamos mas tiempo de procesamiento para pintar en las diferentes salidas que necesitemos. La verdad es que a pesar de consumir mas tiempo del procesador si es muy necesario el uso de un framework para esta funcionalidad por eso voy a listar los motivos por los cuales uso el log4j para manejar mis archivos de log.

1. Todo framework tiene como objetivo el facilitarnos las tareas de algún campo en especifico y log4j no es la excepción a la regla puesto que su principal objetivo es ayudarnos con el manejo de los logs de nuestra aplicación ofreciéndonos una gran variedad de configuraciones que nos permitirán concentrarnos en nuestro problema real: Desarrollar una aplicación y no en desarrollar un buen manejo de logs.
2. Para realizar una buena configuración de log4j no se requiere tener conocimientos extremos de como abrir y cerrar un flujo y si lo estamos haciendo de la forma correcta o no, simplemente tenemos que utilizar los appenders que estan definidos como parte del framework dentro de los cuales tenemos el ConsoleAppender para escribir en la salida estándar, el DayliRollingFileAppender si deseamos que se cree un archivo de log cada dia que pasa, el RollingFileAppender el cual escribe de manera circular cada vez que el archivo llega a un determinado tamaño, el AsyncAppender para escribir de manera asíncrona en el archivo entre otros. En caso ninguno sea de nuestro agrado se puede extender (tomarlo como heredar de la clase o basarse en ella) cualquiera de estos a fin de obtener el manejo esperado.
3. Otra de las funcionalidades que tenemos es el formateo del mensaje a escribir esto lo hacemos usando plantillas que se llaman Layout, cada uno de estos describe el formato en el cual se escribirán nuestros mensajes, dentro de estos tenemos al HTMLLayout el cual ingresa cada uno de los logs como una linea de una tabla, el PatternLayout (el que mas uso) el cual escribe el log en base a un patrón ingresado en el archivo de configuración, el SimpleLayout el cual solamente describe el nivel del log y el mensaje, entre otros. Al igual que los Appender si ningún Layout es de nuestro agrado podemos crear el propio que cumpla con nuestro requerimiento, personalmente no he tenido la oportunidad de realizar dicha tarea puesto que con el PatternLayout realizo todas mis tareas.
4. Otra de las características que me agrada de este framework es el manejo de varios niveles del mensaje los cuales son: TRACE, DEBUG, INFO, WARN, ERROR y FATAL. El como manejarlos puede depender de cada uno, mi sugerencia es manejar cada mensaje informativo entre el TRACE, DEBUG e INFO el uso de cada uno deberá ser en el grado de importancia que se desee tener, para el caso de los mensajes en WARN lo utilizo para mostrar algún evento en el sistema que no es un error pero que si seria bueno documentarlo a fin de mostrar una advertencia en el log, el uso del ERROR es para mostrar errores del sistema y el FATAL es cuando queremos pintar algún mensaje antes de detener el servicio totalmente. Esta es la "formula" que hasta el momento me ha servido para manejar los niveles de mis mensajes.
5. El manejo de diferentes fuentes de impresión del log dependerá de la cantidad de Appenders que nosotros registremos en nuestra configuración, para el programador el escribir en una fuente o en cinco es transparente el solo tiene que decir que tipo de mensaje quiere imprimir y el framework se encargará de realizar las impresiones necesarias. En el caso de utilizar el sysout uno debe de indicar manualmente donde realiza la impresión y si se quiere quitar una fuente se deberla de volver a compilar la aplicación a fin de efectuar el cambio.
6. Regresando a los niveles de log el utilizar un nivel u otro y mostrar o algunos mensajes o no es tan trivial como modificar un archivo de configuración (properties o xml) el desarrollador no tiene que modificar código fuente para realizar el cambio y mucho menos tiene que recompilar la aplicación para realizar estos cambios, lo cual lo pone un paso adelante del manejo del sysout.
7. Finalmente la mejor opción por la cual usuaria el log4j en vez del sysout es por que si realizo un buen uso de los niveles de mensajes en el código no requiero iniciar la aplicación en modo debug lo cual nos ahorra tiempo al momento de depurar errores puesto que todos estos se encuentran debidamente documentados en un archivo, consola, base de datos, etc.

Si a pesar de todo esto aun no quieres usar el log4j o algún otro framework pues solo me queda decirte que mas adelante tendrás muchos problemas o acabarás creando tu propio framework para pintar tus eventos. Para que reinventar la rueda si esta funciona y muy bien, espero este post sea de su agrado.