2010-09-09 11 views
13

Stiamo migrando al logback da log4j per diverse app Web. Nel arresto della nostra applicazione che attualmente chiamiamo:Devo scaricare eventi durante lo spegnimento utilizzando il logback?

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

che dovrebbe irrigare tutta la registrazione asincrona e chiudere tutte le risorse esterne (file, socket).

C'è qualcosa di simile nel logback o in qualche modo si scarica automaticamente all'arresto?

Mike

+0

Domanda interessante - non avevo mai davvero pensato a questo. Dal momento che devi configurare in modo esplicito log4j sull'output del buffer, avrei pensato che in quel caso lo shutdown avrebbe dovuto essere chiamato. Credo che i buffer slf4j di default, però. –

+2

si ripristina dopo ogni istruzione di registro, quindi non è necessario effettuare una chiamata esplicita() a meno che non si stia facendo qualcosa di funky. –

+2

@DavidRoussel Quella dichiarazione mi ha fatto cercare [Logback Appenders] (http://logback.qos.ch/manual/appenders.html). Infatti: _Per impostazione predefinita, ogni evento di registro viene immediatamente svuotato al flusso di output sottostante. Questo approccio predefinito è più sicuro, nel senso che gli eventi di registrazione non vengono persi nel caso in cui l'applicazione venga chiusa senza chiudere correttamente gli appendici. Tuttavia, per un significativo incremento della velocità di registrazione, è possibile impostare la proprietà immediateFlush dell'encoder sottostante su false. Gli encoder e, in particolare, LayoutWrappingEncoder sono descritti in un capitolo a parte. –

risposta

0

Io non sono a conoscenza di uno Shutdown Manager generale come log4j di ma chiudo tutte le mie singole logger contesto quando il loro contesto viene distrutto utilizzando un ServletContextListener in questo modo:

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); 
} 

Inoltre, LoggerContext .stop() è svailable e fa alcune delle stesse funzioni internamente ma non lo uso, quindi non posso commentare se è meglio che resettare o meno.

7

Ecco un approccio semplice:

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

Sembra che solo l'aggiunta di <shutdownHook/> nella configurazione dovrebbe smettere di contesto.

Da logback docs:

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

E da DelayingShutdownHook summary:

implementazione ShutdownHook che ferma contesto Logback dopo un ritardo prestabilito. Il ritardo predefinito è 0 ms (zero).

Problemi correlati