que - ¿Cómo se reduce el código repetitivo de registro de Java?

que pasa si desinstalo java

Question

Cada clase que quiera usar java.util.logging generalmente necesita declarar un registrador como este:

public class MyClass {
    private static Logger _log = Logger.getLogger(MyClass.class.getName());
}

¿Cómo se evita este código repetitivo de MyClass.class.getName ()?

Answer 1

Dependiendo de sus necesidades de registro, puede crear una clase "LoggingService" con métodos estáticos para iniciar sesión en varios "canales". Descubrí que realmente no necesito granularidad de registro hasta el nivel de clase. Puede nombrar sus registradores lo que mejor funciona para usted. Hemos estado usando esto en aplicaciones empresariales grandes durante varios años y la granularidad realmente no ha sido un problema para nosotros.

El servicio de inicio de sesión se inicializó en un bloque de inicializador estático ... para registrar un mensaje:

LoggingService.logError ("blah");

No hay un código repetitivo en cada clase.

Aquí hay un ejemplo de servicio de registro:

public class LoggingService {

/**
 * A log for informational messages.
 */
static private Logger infoLog;

/**
 * A log for data access messages.
 */
static private Logger dataAccessLog;

/**
 * A log for debug messages.
 */
static private Logger debugLog;

/**
 * A log for error messages.
 */
static private Logger errorLog;

/**
 * A log for all XML related messages.
 */
static private Logger xmlLog;

/**
 * A log for all trace messages.
 */
static private Logger traceLog;

/**
 * A log for all warning messages.
 */
static private Logger warnLog;

static {

    //This is the bootstrap for the logging service.
    //Setup each logger
    infoLog = Logger.getLogger("com.company.logging.info");
    dataAccessLog = Logger.getLogger("com.company.logging.dataaccess");
    debugLog = Logger.getLogger("com.company.logging.debug");
    errorLog = Logger.getLogger("com.company.logging.error");
    xmlLog = Logger.getLogger("com.company.logging.xml");
    traceLog = Logger.getLogger("com.company.logging.trace");
    warnLog = Logger.getLogger("com.company.logging.warn");

    // This must be set so isErrorEnabled() will work.
    errorLog.setLevel(Level.ERROR);
    warnLog.setLevel(Level.WARN);
}
static public void logDataAccess(String pMessage) {
    dataAccessLog.info(pMessage);
}

static public void logInfo(String pMessage) {
    infoLog.info(pMessage);
}

static public void logDebug(String pMessage) {
    debugLog.debug(pMessage);
}

static public void logTrace(String pMessage) {
    traceLog.debug(pMessage);
}

static public void logWarn(String pMessage) {
    warnLog.warn(pMessage);
}

static public void logError(String pMessage) {
    errorLog.error(pMessage);
}

static public void logError(String pMessage, Throwable pThrowable) {
    errorLog.error(pMessage, pThrowable);
}

static public void logXml(String pMessage, XmlBean pContainer) {

    if (!xmlLog.isInfoEnabled()) return;

    xmlLog.info(pMessage + " : " + JAXBHelper.marshal(pContainer));
}

static public boolean isInfoEnabled() {
    return infoLog.isInfoEnabled();
}

static public boolean isDataAccessEnabled() {
    return dataAccessLog.isInfoEnabled();
}

static public boolean isDebugEnabled() {
    return debugLog.isDebugEnabled();
}

static public boolean isErrorEnabled() {
    if (errorLog.getLevel().toInt() >= Level.ERROR_INT) {
        return true;
    }
    return false;
}

static public boolean isTraceEnabled() {
    return traceLog.isDebugEnabled();
}

static public boolean isXmlEnabled() {
    return xmlLog.isInfoEnabled();
}

static public boolean isWarnEnabled() {
    return warnLog.isEnabledFor(Level.WARN);
}

}

Answer 2

Eche un vistazo al uso de cortes de punto en su código

No he mirado hacia atrás desde que los usé con la primavera.

Aquí hay un artículo sobre el uso de AspectJ

http://www.developer.com/java/other/article.php/3109831

Answer 3

Tengo una plantilla configurada en Eclipse para que solo tenga que escribir una parte de la declaración, y luego Eclipse automáticamente completará el resto.

${:import(org.apache.log4j.Logger)}
private final static Logger log = Logger.getLogger(${enclosing_type}.class);
${cursor}

Por lo tanto, solo tengo que escribir logger , presionar Ctrl+Space , seguido de Enter , y Eclipse rellena el resto para mí y agrega la declaración de importación también.

Esto no reducirá la cantidad de código repetitivo, pero al menos reduce la cantidad de teclas presionadas.

Answer 4

Echa un vistazo a SLF4J

Answer 5

No necesita getName () si está usando una versión 1.2+ de log4j, getLogger () acepta un argumento de clase. Pero en cuanto al resto, no hay forma de evitarlo si desea que cada clase tenga un miembro de registro estático con su propia categoría.

Answer 6

Puedes taquicar esto un poquito, ya que getLogger está sobrecargado para simplemente tomar la clase. Al igual que:

public class MyClass {
    private static Logger _log = Logger.getLogger(MyClass.class);
}

El registrador puede ser tan flexible o inflexible como desee. Puede tomar un nuevo registrador para cada clase, como en su ejemplo anterior, y tener una jerarquía de registradores donde puede controlar y activar / desactivar el registro por clase. O si su proyecto es pequeño o un prototipo, etc., puede llamar a Logger.getRootLogger (), pero perderá la flexibilidad de ajustar lo que registra y no registra. Podrías tener una clase base donde vive el registrador y hacer que todos lo llamen, pero nuevamente pierdes algo de flexibilidad:

public class MyBase {
     protected static Logger _log = Logger.getLogger(MyClass.class);
}

public class MyClass extends MyBase {
    ....
    _log.info("Stuff....");
}

En pocas palabras, si desea mantener la capacidad de ajustar su registro más adelante en el proyecto (activar la depuración de nivel más fino para una sola clase), entonces tendrá que seguir con el modelo en todas las clases.

Answer 7

Si busca registradores de nivel de paquete, con la adición de una clase repetitiva por paquete, puede escribir:

private static final Logger log = Logs.log;

Hay hacks para leer el nombre de clase de la persona que llama (de hecho, la implementación de registro tiene un truco para detectar el método actual), pero no lo recomendaría.

Answer 8

Si haces el registrador no estático, al menos lo puedes heredar:

public class SomeBaseClass
{
    protected Logger logger = Logger.getLogger(getClass());
}

public class SubClass extends SomeBaseClass
{
    public void doit() { logger.debug("doit!!!!"); }
}

Así es como siempre lo he hecho.

Answer 9

En realidad, la práctica común de usar nombres de clase para nombres de registradores es más bien floja.

La práctica mucho mejor es nombrar registradores por el contexto de la tarea. Esto implica un poco más de proceso de pensamiento y planificación, pero al final, el resultado es una granularidad mucho más significativa, donde puede alternar los niveles de registro para las tareas reales en lugar de las clases.

Answer 10

Puede reducir ese y muchos otros códigos repetitivos con lombok

https://github.com/rzwitserloot/lombok

 @Slf4j
     public class LogExample {
 }

estarán

 public class LogExample {
     private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class);
 }