2012-10-31 11 views
9

Pomysł polega na umożliwieniu zmiany konfiguracji logowania bez konieczności ponownego wdrażania. Slf4j i logback są używane w projekcie. Plik logback.xml jest w uchu, ale odczytuje niektóre właściwości z pliku właściwości, który jest umieszczony poza zasięgiem ucha. Coś takiego:Zaktualizuj konfigurację logowania bez konieczności ponownego wdrażania.

<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 jest, że kontrole skanowania jeśli logback.xml został zmieniony (i złożyć zawsze takie same). Dlatego zmiana wartości w pliku właściwości nie zmienia konfiguracji logback. Zmiany są stosowane tylko po przeniesieniu.

Jaki jest najlepszy sposób, aby zmodyfikować konfigurację logowania bez konieczności ponownego wdrażania? Czy jest jakiś mechanizm, który pozwala to zrealizować?

upd: zmiany byłyby wprowadzane bardzo rzadko. ale powinny być stosowane tak szybko, jak to możliwe. wydajność jest również ważna.

+1

Nie można programowo wprowadzić pewne zmiany do manekina plik logback.xml, aby został ponownie załadowany? Podobnie jak dodawanie i usuwanie pustych linii na końcu pliku? – rolve

+0

@rolve Myślałem o takiej pracy. Ale mam nadzieję, że musi być wygodniejszy sposób na zrobienie tego. – error1009

Odpowiedz

0

Po pewnym porównaniu wydaje mi się, że wygodniej jest umieścić logback.xml z ucha. Można to zrealizować, określając właściwość systemowa logback.configurationFile w konfiguracji serwera. Aby ułatwić edycję dla ludzi, planuję zdefiniować niektóre właściwości na początku pliku. Tak

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

a następnie wykorzystać je w konfiguracji

<pattern>${consolePattern}</pattern> 

będzie obsługiwać problem z dynamicznych zmian i jest prawie przyjazny dla użytkownika))

5

udaje mi się przeładować go w ten sposób:

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

W moim przypadku użycia, to zrobić, aby dodać pewne właściwości do kontekstu, wykonując:

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

przed autoconfig.

Właściwości odczytu z pliku właściwości również powinny działać.

+0

Niestety, wymagałoby to, aby kod aplikacji był świadomy implementacji rejestrowania, a nie interfejsów, ponieważ LoggerContext jest klasą logback. Jest to oczywiście zakładanie, że plakat używa slf4j jako elewacji logowania, co jest zalecane. –

+0

Proponujesz zatem sprawdzenie zmian w pliku właściwości. i ponownie załadować konfigurację, jeśli właściwości zostały zmienione? To powinno zadziałać, ale myślę, że nie nadaje się do wykonania. – error1009

3

Być może polecenie "dotknij" przyda się do fikcyjnej modyfikacji pliku po ustawieniu właściwości.

Powiązane problemy