Configura configurazione di aggiornamento senza ridistribuire

L'idea è di rendere possibile modificare la configurazione di logback senza ridistribuire. Slf4j e logback sono usati nel progetto. logback.xml è in ascolto, ma legge alcune proprietà dal file di proprietà, che viene messo fuori dall'orecchio. Qualcosa del genere:Configura configurazione di aggiornamento senza ridistribuire

<configuration scan="true" scanPeriod="5 seconds"> 
<property file="${logconfig}"/> 

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
    <encoder> 
     <pattern>${logback.consolePattern}</pattern> 
    </encoder> 
</appender> 
<root level="DEBUG"> 
    <appender-ref ref="STDOUT" /> 
</root> 

</configuration>

Il problema è che i controlli di scansione se logback.xml è stato modificato (e il file sempre la stessa). Ecco perché la modifica dei valori nel file delle proprietà non modifica la configurazione del logback. Le modifiche vengono applicate solo dopo la ridistribuzione.

Allora, qual è il modo migliore per avere la capacità di modificare la configurazione logback senza redeploy? C'è qualche meccanismo che permette di realizzarlo?

UPD: modifiche sarebbero state molto raramente. ma dovrebbero essere applicati il prima possibile. anche le prestazioni sono importanti.

fonte

2012-10-31 error1009

Non potresti apportare alcune modifiche a livello di codice fittizio per la logback.xml in modo che venga ricaricato? Come aggiungere e rimuovere righe vuote alla fine del file? – rolve

@rolve Ho pensato a un simile lavoro. Ma spero che ci debba essere un modo più conveniente per farlo. – error1009

Dopo un po 'il confronto penso che sarebbe stato più facile e più comodo per posizionare logback.xml di orecchio. Può essere realizzato specificando la proprietà di sistema logback.configurationFile nella configurazione del server. Per rendere la modifica più comoda per le persone, ho intenzione di definire alcune proprietà all'inizio del file. Come quella

<property name="consolePattern" value="%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"/>

E poi utilizzarli in configurazione

<pattern>${consolePattern}</pattern>

tratterà problema con cambiamenti dinamici ed è quasi userfriendly))

fonte

2012-11-01 13:52:22 error1009

riesco a ricaricarlo in questo modo:

LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory(); 
loggerContext.reset(); 
ContextInitializer ci = new ContextInitializer(loggerContext); 
ci.autoConfig();

Nel mio caso d'uso, lo faccio per aggiungere alcune proprietà al contesto facendo:

loggerContext.putProperty("logDirectory", getLogDirectory().getAbsolutePath());

prima della autoConfig.

proprietà di lettura dal file proprietà devono lavorare troppo.

fonte

2012-10-31 14:58:43

Questo, purtroppo, richiederebbe che il codice dell'applicazione fosse a conoscenza dell'implementazione della registrazione piuttosto che delle interfacce, poiché LoggerContext è una classe di logback. Questo è, naturalmente, assumendo che il poster usi slf4j come facciata del logging, come raccomandato. –

Quindi si propone di verificare le modifiche nel file delle proprietà. e ricarica la configurazione se le proprietà sono state modificate? Dovrebbe funzionare, ma penso che non sia buono per le perfomance. – error1009

Forse comando "touch" sarà utile per una modifica del file fittizio, dopo le proprietà impostate.

fonte

2012-10-31 15:00:17 Gosha

Configura configurazione di aggiornamento senza ridistribuire

risposta

Problemi correlati