¿Dónde se define un registrador estático de toda la aplicación?

Question

Tengo una serie de paquetes en mi aplicación web Java. En algunos de ellos utilizo este constructo:

public class Foo { 
    private static Logger logger = LoggerFactory.getLogger("com.XXX"); 
    public void bar() { 
    Foo.logger.debug("Method bar() was just called"); 
    } 
} 

Por supuesto, es solo un ejemplo. Todo funciona bien, pero no me gusta la idea de la inicialización del registrador en muchas clases. Es una duplicación de código obvia. Me gustaría moverlo a alguna clase de ayuda y permitir que todas las otras clases accedan a él. ¿Es una idea correcta? ¿O tal vez hay alguna otra "mejor práctica" o un patrón?

Answer 1

Puede escribir su propia clase de utilidad que envuelve el registrador global e implementa delegados estáticos en los métodos del registrador. A continuación, sólo hacer una importación estática de esta clase:

public class MyLogger { 
    private static Logger logger = LoggerFactory.getLogger("application"); 

    public static void debug(String s) {logger.debug(s));} 

    public static void debug(Class<?> caller, String s) { 
    LoggerFactory.getLogger(caller.getName()).debug(s); 
    } 

    // ... 
} 

Uso:

import static MyLogger.*; 

public class Foo { 
    public void bar() { 
    // makes use of static import! 
    debug("Method bar() was just called"); 
    debug(this.getClass(), "Method bar() was just called"); 
    } 
} 

añadido una versión sobrecargada del ejemplo debug delegado que toma un objeto de clase y utiliza el registrador apropiado.

Answer 2

Creo que está buscando el patrón de diseño de Singleton. Al no ser un programador de Java, cavé esto desde Google:

http://www.javacoffeebreak.com/articles/designpatterns/index.html

Answer 3

Se puede crear un Adapter pattern de registrador. En mi caso, extendí el registrador para incluir toda la funcionalidad del registrador. Esto se convierte en Singleton.

public class LoggerAdapter extends Logger { 
    private LoggerAdapter instance; 
    private Logger logger; 

    private LoggerAdapter() { 

    } 

    public static LoggerAdapter getInstance(Clazz<?> clazz) { 
     if (instance == null) { 
      instance = new LoggerAdapter(); 
     } 
     instance.logger = logger = LoggerFactory.getLogger(clazz.getName()); 

     return instance; 
    } 

    @Override 
    public void trace(Object object) { 
     logger.trace(object); 
    } 

    //Other overridden methods here... 
}; 

Básicamente, un registrador dinámica cambiante ....

Answer 4

no creo que va a ganar nada si utiliza centralizado registrador estático mundial constrcut que no sea el Log4J común llama/INIT.

Si se escribe

private static Logger logger = LoggerFactory.getLogger("com.XXX"); 
logger.info("Hello World"); 

o algo así

GlobalLogger.info(this, "LogMessage"); //Singleton... 

... no hará que su código sea más "legible".

Answer 5

Esto no se recomienda ya que perderá las capacidades de registro jerárquico de Log4j (si eso es lo que está usando), donde es muy beneficioso agregar diferentes appenders en diferentes niveles de su árbol de paquetes. No haría esto ya que perdería información sobre qué clase creó el mensaje de registro.

Answer 6

Decir que esto es duplicación de código es como decir que tener import java.util.* en el 75% de las clases es una duplicación de código. O que te encuentres escribiendo public class ... con demasiada frecuencia. No está duplicando lógica. Está duplicando el código repetitivo.

La duplicación de código es solo cuando huele a lógica de duplicación. Si hay demasiado código repetitivo, es el diseño del lenguaje huele realmente. Nada de lo que realmente deberías estar preocupado.

En el lado negativo, pierde la capacidad de ajustar su registro si abandona la estructura jerárquica.

Answer 7

El encapsulado de una dependencia tercera parte (es decir, Log4J) con una clase de logger utilidad tiene sentido.

Por ejemplo, si un equipo decide cambiar de Log4j a NextBigThingLogger, simplemente actualiza su clase MyLogger y ninguna de las otras clases de aplicaciones.

limpiador y un mantenimiento más fácil.

API Apache, e incluso el propio lenguaje Java, están llenos de "diseño huele", pero eso no quiere decir que no debemos responder a ellos.