2012-10-31 7 views
9

Idee ist es, die Logback-Konfiguration zu ändern, ohne erneut zu implementieren. Slf4j und Logback werden im Projekt verwendet. Logback.xml-Datei ist im Ohr, aber es liest einige Eigenschaften aus der Eigenschaft Datei, die außerhalb des Ohres platziert wird. So etwas:Update Logback-Konfiguration ohne erneute Bereitstellung

<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> 

Problem ist, dass Scan überprüft, ob logback.xml geändert wurde (und die Datei immer gleich). Aus diesem Grund ändert das Ändern der Werte in der Eigenschaftendatei nicht die Konfiguration des Logbacks. Änderungen werden erst nach einer erneuten Bereitstellung übernommen.

Was ist also der beste Weg, die Logback-Konfiguration zu ändern, ohne sie erneut zu implementieren? Gibt es einen Mechanismus, der es erlaubt, es zu realisieren?

upd: Änderungen würden sehr selten vorgenommen. aber sie sollten so bald wie möglich angewendet werden. Leistung ist auch wichtig.

+1

konnte nicht programmatisch Sie einige Dummy-Änderungen an der machen Logback.xml-Datei, so dass es neu geladen wird? Wie das Hinzufügen und Entfernen von Leerzeilen am Ende der Datei? – rolve

+0

@rolve Ich dachte über solche Arbeit um. Aber ich hoffe, es muss einen bequemeren Weg geben, das zu tun. – error1009

Antwort

0

Nach einigem Vergleich denke ich, dass es einfacher und bequemer wäre, logback.xml aus dem Ohr zu legen. Dies kann durch Angabe der Systemeigenschaft logback.configurationFile in der Serverkonfiguration realisiert werden. Um die Bearbeitung für Leute bequemer zu machen, plane ich einige Eigenschaften am Anfang der Datei zu definieren. Wie das

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

Und sie dann in der Konfiguration verwenden

<pattern>${consolePattern}</pattern> 

Es Problem mit dynamischen Änderungen behandelt, und es ist fast anwenderfreundlich))

5

schaffe ich es neu zu laden, indem Sie diese:

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

In meinem Anwendungsfall, das tue ich, dass einige Eigenschaften auf den Kontext hinzufügen, indem Sie:

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

vor dem autoConfig.

Lesen von Eigenschaften aus der Eigenschaftendatei sollte auch funktionieren.

+0

Dies würde bedauerlicherweise erfordern, dass der Anwendungscode die Implementierung der Protokollierung und nicht die Schnittstellen kennt, da LoggerContext eine Logback-Klasse ist. Dies ist natürlich vorausgesetzt, das Poster verwendet slf4j als Protokollierung Fassade, wie es empfohlen wird. –

+0

Sie schlagen also vor, Änderungen in der Eigenschaftendatei zu überprüfen. und Konfiguration neu laden, wenn die Eigenschaft geändert wurde? Es sollte funktionieren, aber ich denke, es ist nicht gut für die Leistung. – error1009

3

Vielleicht Befehl "Touch" wird nützlich sein für eine fiktive Datei Änderung, nach Eigenschaften festgelegt.