2010-09-09 16 views
13

Estamos migrando a logback desde log4j para varias aplicaciones web. En el cierre de nuestra aplicación actualmente llamamos:¿Debo limpiar los eventos al cerrar usando logback?

org.apache.log4j.LogManager.shutdown(); 

que se supone para limpiar todo el registro asíncrono y cerrar todos los recursos externos (archivos, enchufes).

¿Hay algo similar en el logback o de alguna manera se vacía automáticamente al apagarlo?

Mike

+0

pregunta interesante - Me nunca pensé en esto. Como tiene que configurar explícitamente log4j en la salida del búfer, habría supuesto que el cierre solo debería llamarse en ese caso. Sin embargo, creo que los búfers slf4j por defecto. –

+2

logback se vacía después de cada declaración de registro, por lo que no es necesario realizar una llamada explícita a stop() a menos que esté haciendo algo funky. –

+2

@DavidRoussel Esa afirmación me hizo buscar [Logback Appenders] (http://logback.qos.ch/manual/appenders.html). De hecho: _Por defecto, cada evento de registro se vacía inmediatamente a la secuencia de salida subyacente. Este enfoque predeterminado es más seguro en el sentido de que los eventos de registro no se pierden en caso de que su aplicación finalice sin cerrar adecuadamente los appenders. Sin embargo, para un rendimiento de registro significativamente mayor, es posible que desee establecer la propiedad InstantFlush del Encoder subyacente en falso. Los codificadores y, en particular, LayoutWrappingEncoder se describen en un capítulo separado. –

Respuesta

0

No estoy al tanto de un apagado general gerente como log4j de pero cierro todos mis madereros contexto individual cuando su contexto se destruye utilizando un ServletContextListener así:

ContextSelector selector = StaticLoggerBinder.getSingleton().getContextSelector(); 
LoggerContext context = selector.detachLoggerContext(contextName); 
if (context != null) { 
    Logger logger = context.getLogger(Logger.ROOT_LOGGER_NAME); 
    context.reset(); 
} else { 
    System.err.printf("No context named %s was found", contextName); 
} 

Además, LoggerContext .stop() está disponible y realiza algunas de las mismas funciones internamente, pero no las uso, por lo que no puedo comentar si es mejor que restablecerlas o no.

7

Aquí es un enfoque simple:

import org.slf4j.ILoggerFactory; 
import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 

import ch.qos.logback.classic.LoggerContext; 

... 

ILoggerFactory loggerFactory = LoggerFactory.getILoggerFactory(); 
// Check for logback implementation of slf4j 
if (loggerFactory instanceof LoggerContext) { 
    LoggerContext context = (LoggerContext) loggerFactory; 
    context.stop(); 
} 
7

Parece que sólo añadir <shutdownHook/> en la configuración debe detener el contexto.

De logback docs:

<configuration> 
    <!-- in the absence of the class attribute, assume 
    ch.qos.logback.core.hook.DelayingShutdownHook --> 
    <shutdownHook/> 
    .... 
</configuration> 

Y a partir de DelayingShutdownHook summary:

aplicación ShutdownHook que detiene el contexto Logback después de un retardo especificado. El retraso predeterminado es 0 ms (cero).

Cuestiones relacionadas