Log4J
Log4J es una librería para resolver el log de aplicaciones Java.
Contenido
Los Appender
Log4J utiliza "appenders" para guardar el log generado por las aplicaciones. Un appender es el encargado de procesar un mensaje de log enviado por la aplicación. Usualmente se encarga de almacenarlo en algún medio persistente, como ser un archivo.
Existen distintos appenders para guardar logs en archivos, base de datos o colas de mensajeria.
JMSAppnder
Log4J cuenta con un Appender especial que redirecciona los eventos de log a un Topic JMS.
El appender a utilizar es org.apache.log4j.net.JMSAppender, el cual se encarga de enviar los eventos de log a un Topic asociado. Un topic es parecido a una cola, pero con la diferencia que los mensajes se distribuyen a todos los suscriptores de la misma. Si no hay suscriptores, el mensaje se pierde.
El JMSAppnder es muy útil en un ambiente en cluster, para centralizar la información de los log en un único lugar.
Ejemplo de uso
En la práctica, utilizar log4j con este appender es igual que en cualquier otro caso. En el archivo de configuración log4j.properties es necesario agregar el appender en cuestión.
log4j.logger.com.zim=DEBUG, jms log4j.appender.jms=org.apache.log4j.net.JMSAppender log4j.appender.jms.InitialContextFactoryName=weblogic.jndi.WLInitialContextFactory log4j.appender.jms.ProviderURL=t3://miApplicationServer:7001 log4j.appender.jms.TopicConnectionFactoryBindingName=JmsZimCF log4j.appender.jms.TopicBindingName=ZimTopic log4j.appender.jms.locationInfo=true
En el ejemplo, utilizamos el Connection Factory JmsZmiCF para conectarnos al topic ZimTopic (ambos teniendo que estar configurados en algún Servidor de Aplicaciones).
Con esta configuración odos los logs de las clases que pertenezcan al paquete "com.zim" se enviaran como mensajes al topic. Al Topic se envian objetos de tipo LoggingEvent, clase que contiene la información de un evento de log.
Luego, podrá haber distintos suscriptores que tomen las acciones necesarias sobre el mensaje. Por ejemplo, podriamos tener suscriptores que guarden el log en una base de datos, u otros que envien un mail o sms.
Sobre el locationInfo
Por default, el atributo locationInfo está en "false". Esto hace que NO se envien los datos para el objeto LocationInfo de LoggingEvent. Al setearlo en true, el objeto LocationInfo contendrá la información sobre la clase, método y número de línea en donde ocurrió el error.
Procesando el mensaje
Luego, queda tan solo decidir qué hacer con el mensaje. Usualmente, será un Message Driven Bean que procese de alguna manera el mensaje que envia Log4J.
¿Y qué envia exactamente? Log4J enviará un ObjectMessage de JMS, que contiene una instancia de LoggingEvent, la cual contiene la información relativa al log que generó la aplicación.
Log4j en J2EE, en servidores WebLogic
Si queres compartir los mismos componentes log4j en un módulo EJB y Web, y el EJB se usa localmente, en el ear tienen que estar el EJB y el Web. El log4-*.jar en /APP-INF/lib, y log4.properties en /APP-INF/classes. /APP-INF/ en la raíz del ear.
Y dentro del build-impl.xml del ear, los sgtes. pasos para la tarea que crea el META-INF:
<copy todir="${build.dir}/APP-INF/lib">
<fileset file="${log4j.jar}"/>
</copy>
<copy todir="${build.dir}/APP-INF/classes">
<fileset file="${log4j.properties}"/>
</copy>
Log4J en Debug
Se puede usar el argumento -Dlog4j.debug como parametro para la JVM y muestra algunas cosas de log4J por consola, como por ejemplo, el archivo desde donde está levantando las propiedades.
