Diferencia entre revisiones de «Log4J»

Revisión del 15:04 27 jul 2008

Log4J es una librería para resolver el log de aplicaciones Java.

Los Appender

Log4J utiliza "appenders" para guardar el log generado por las aplicaciones. Existen distintos appenders para guardar logs a 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.

Ver también

• Web oficial de Log4J
• [Javadoc del LogginEvent | http://logging.apache.org/log4j/docs/api/org/apache/log4j/spi/LoggingEvent.html ]