Diferencia entre revisiones de «Log4J»
(→Obtención del Logger) |
|||
| Línea 66: | Línea 66: | ||
===Los modificadores=== | ===Los modificadores=== | ||
| − | + | ====private==== | |
| − | |||
Por lo general queremos que el logger se reporte como la clase que se está ejecutando. Utilizando private nos aseguramos que una clase que herede tenga que declarar su propio Logger y no usará accidentalmente el de la superclase. Contrariamente, si queremos por granularidad que utilice el de la superclase, habrá que declararlo como protected. | Por lo general queremos que el logger se reporte como la clase que se está ejecutando. Utilizando private nos aseguramos que una clase que herede tenga que declarar su propio Logger y no usará accidentalmente el de la superclase. Contrariamente, si queremos por granularidad que utilice el de la superclase, habrá que declararlo como protected. | ||
| − | + | ====final==== | |
La referencia al logger es la misma durante todo el ciclo de vida de una clase (si se declara static) o de un objeto (si es atributo de instancia). Por lo tanto, declarándola final se expresa esto, se protege a una asignación errónea y se mejora la performance. | La referencia al logger es la misma durante todo el ciclo de vida de una clase (si se declara static) o de un objeto (si es atributo de instancia). Por lo tanto, declarándola final se expresa esto, se protege a una asignación errónea y se mejora la performance. | ||
| − | + | ====static==== | |
La creación del Logger está administrada por una fábrica a la que le pedimos las instancias. Es responsabilidad de la fábrica darnos la instancia correcta. En este caso, la motivación de utilizar static no es la de tener una sola copia. La motivación es que los logger no deben serializarse, deberían ser transient. Siendo static es una variable de la clase y no un atributo de la instancia, por lo que no será serializado. La razón de no marcarlo como transient (que sería conceptualmente más acertado) es que se debería implementar un mecanismo para que cuando la instancia es des-serializada, vuelva a obtener una copia del logger. | La creación del Logger está administrada por una fábrica a la que le pedimos las instancias. Es responsabilidad de la fábrica darnos la instancia correcta. En este caso, la motivación de utilizar static no es la de tener una sola copia. La motivación es que los logger no deben serializarse, deberían ser transient. Siendo static es una variable de la clase y no un atributo de la instancia, por lo que no será serializado. La razón de no marcarlo como transient (que sería conceptualmente más acertado) es que se debería implementar un mecanismo para que cuando la instancia es des-serializada, vuelva a obtener una copia del logger. | ||
| − | + | ====transient==== | |
Los logger no deben ser serializados, por eso deberían ser marcados como transient. Es más fácil marcarlos como static ya que de esta forma no es necesario volver a obtenerlos cuando la clase es des-serializada. Si la clase no es serializable, no es necesario. | Los logger no deben ser serializados, por eso deberían ser marcados como transient. Es más fácil marcarlos como static ya que de esta forma no es necesario volver a obtenerlos cuando la clase es des-serializada. Si la clase no es serializable, no es necesario. | ||
| − | |||
===Clave para la obtención del logger=== | ===Clave para la obtención del logger=== | ||
| − | |||
El logger se le pide a la fábrica a través de una clave. Esta clave es de tipo String. El método está sobrecargado para recibir también un objeto de tipo class que luego la fábrica convertirá a String. | El logger se le pide a la fábrica a través de una clave. Esta clave es de tipo String. El método está sobrecargado para recibir también un objeto de tipo class que luego la fábrica convertirá a String. | ||
| − | + | ====String==== | |
| − | |||
private static final Logger log = Logger.getLogger("com.foo.bar.Blah"); | private static final Logger log = Logger.getLogger("com.foo.bar.Blah"); | ||
Utilizando un String se obtiene un logger independientemente de la clase donde se esté. Si lo que se busca el logger para la clase, esta es la forma más riesgosa ya que no está verificada por el compilador. | Utilizando un String se obtiene un logger independientemente de la clase donde se esté. Si lo que se busca el logger para la clase, esta es la forma más riesgosa ya que no está verificada por el compilador. | ||
| − | + | ====Objeto class==== | |
private static final Logger log = Logger.getLogger(Blah.class); | private static final Logger log = Logger.getLogger(Blah.class); | ||
Utilizando un objeto de tipo Class permite que el compilador verifique el nombre de la clase. También se actualiza si se utiliza alguna herramienta o IDE para cambiar el nomre de la clase. | Utilizando un objeto de tipo Class permite que el compilador verifique el nombre de la clase. También se actualiza si se utiliza alguna herramienta o IDE para cambiar el nomre de la clase. | ||
| − | + | ====método getClass()==== | |
private final Logger log = Logger.getLogger(getClass()); | private final Logger log = Logger.getLogger(getClass()); | ||
En este caso la clave se genera en tiempo de ejecución pidiendo al objeto su clase a través del método getClass(). Esto tiene la ventaja de que siempre tendrá el nombre apropiado de la clase. Tiene la restricción de que sólo se podrá utilizar si el logger es un atributo de la clase (no static). | En este caso la clave se genera en tiempo de ejecución pidiendo al objeto su clase a través del método getClass(). Esto tiene la ventaja de que siempre tendrá el nombre apropiado de la clase. Tiene la restricción de que sólo se podrá utilizar si el logger es un atributo de la clase (no static). | ||
Revisión del 13:24 13 nov 2009
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.
Obtención del Logger
Existe una serie de variantes para definir y obtener el logger de una clase:
Los modificadores
private
Por lo general queremos que el logger se reporte como la clase que se está ejecutando. Utilizando private nos aseguramos que una clase que herede tenga que declarar su propio Logger y no usará accidentalmente el de la superclase. Contrariamente, si queremos por granularidad que utilice el de la superclase, habrá que declararlo como protected.
final
La referencia al logger es la misma durante todo el ciclo de vida de una clase (si se declara static) o de un objeto (si es atributo de instancia). Por lo tanto, declarándola final se expresa esto, se protege a una asignación errónea y se mejora la performance.
static
La creación del Logger está administrada por una fábrica a la que le pedimos las instancias. Es responsabilidad de la fábrica darnos la instancia correcta. En este caso, la motivación de utilizar static no es la de tener una sola copia. La motivación es que los logger no deben serializarse, deberían ser transient. Siendo static es una variable de la clase y no un atributo de la instancia, por lo que no será serializado. La razón de no marcarlo como transient (que sería conceptualmente más acertado) es que se debería implementar un mecanismo para que cuando la instancia es des-serializada, vuelva a obtener una copia del logger.
transient
Los logger no deben ser serializados, por eso deberían ser marcados como transient. Es más fácil marcarlos como static ya que de esta forma no es necesario volver a obtenerlos cuando la clase es des-serializada. Si la clase no es serializable, no es necesario.
Clave para la obtención del logger
El logger se le pide a la fábrica a través de una clave. Esta clave es de tipo String. El método está sobrecargado para recibir también un objeto de tipo class que luego la fábrica convertirá a String.
String
private static final Logger log = Logger.getLogger("com.foo.bar.Blah");
Utilizando un String se obtiene un logger independientemente de la clase donde se esté. Si lo que se busca el logger para la clase, esta es la forma más riesgosa ya que no está verificada por el compilador.
Objeto class
private static final Logger log = Logger.getLogger(Blah.class);
Utilizando un objeto de tipo Class permite que el compilador verifique el nombre de la clase. También se actualiza si se utiliza alguna herramienta o IDE para cambiar el nomre de la clase.
método getClass()
private final Logger log = Logger.getLogger(getClass());
En este caso la clave se genera en tiempo de ejecución pidiendo al objeto su clase a través del método getClass(). Esto tiene la ventaja de que siempre tendrá el nombre apropiado de la clase. Tiene la restricción de que sólo se podrá utilizar si el logger es un atributo de la clase (no static). Otra particularidad es que el método getClass() invocado en una clase padre responderá desde la clase hija. En caso de que el objeto sea serializable habrá que agregar el modificador transient para que no se serialice el logger.
private transient Logger log = Logger.getLogger(getClass());
Conclusión
La forma práctica de no cometer errores es la de utilizar la combinación más restrictiva y sólo cambiarla si se necesita por alguna razón claramente justificada e implementando los mecanismos que implique. Ejemplo:
public class Blah {
private static final Logger log = Logger.getLogger(Blah.class);
}
