2013-05-28 33 views
10

Ostatnio eksperymentowałem z logback i korzystam z przykładów bezpośrednio z poziomu Eclipse. Kiedy to robię, zauważam, że - nawet po zakończeniu mojej statycznej metody main(String[] args) (z poziomu mojej klasy sterownika Java), aplikacja nadal działa.Zatrzymywanie systemu logowania do czystego zamykania

W końcu stwierdziłem, że Logback zarządza własnymi wątkami, które pozostają przy życiu nawet po wyjściu głównej aplikacji. I googled wokół niektórych rozwiązań i znalazłem to jako sposób jawnie zamykając Logback od wewnątrz Java:

ILoggerFactory factory = LoggerFactory.getILoggerFactory(); 
if(factory instanceof LoggerContext) { 
    LoggerContext ctx = (LoggerContext)factory; 
    ctx.stop(); 
} 

to jest naprawdę jedynym sposobem na zamknięcie logback czysto? Nigdy nie spotkałem się z systemem rejestrowania (JUL, JCL, log4j itd.), Który powoduje, że jawnie go wyłączysz, aby z gracją wyjść z aplikacji ...

Z góry dziękuję!

Aktualizacja: oto logback.xml:

<configuration debug="true" scan="true" scanPeriod="5 minutes"> 
    <appender name="logManager-consoleAppender" class="ch.qos.logback.core.ConsoleAppender"> 
     <filter class="ch.qos.logback.classic.filter.LevelFilter"> 
      <level>TRACE</level> 
      <onMatch>ACCEPT</onMatch> 
      <onMismatch>NEUTRAL</onMismatch> 
     </filter> 
     <filter class="ch.qos.logback.classic.filter.LevelFilter"> 
      <level>DEBUG</level> 
      <onMatch>ACCEPT</onMatch> 
      <onMismatch>DENY</onMismatch> 
     </filter> 
     <encoder> 
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> 
     </encoder> 
    </appender> 

    <appender name="logManager-smtpAppender" class="ch.qos.logback.classic.net.SMTPAppender"> 
     <filter class="ch.qos.logback.classic.filter.LevelFilter"> 
      <level>WARN</level> 
      <onMatch>ACCEPT</onMatch> 
      <onMismatch>NEUTRAL</onMismatch> 
     </filter> 
     <filter class="ch.qos.logback.classic.filter.LevelFilter"> 
      <level>ERROR</level> 
      <onMatch>ACCEPT</onMatch> 
      <onMismatch>DENY</onMismatch> 
     </filter> 
     <smtpHost>my.smtp.host</smtpHost> 
     <to>[email protected]</to> 
     <from>[email protected]</from> 
     <username>my_user</username> 
     <password>my_password</password> 
     <subject>%logger{20} - %m</subject> 
     <layout class="ch.qos.logback.classic.html.HTMLLayout"/> 
     <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker"> 
      <bufferSize>5</bufferSize> 
     </cyclicBufferTracker> 
    </appender> 

    <root level="ALL"> 
     <appender-ref ref="logManager-consoleAppender" /> 
     <appender-ref ref="logManager-smtpAppender" /> 
    </root> 
</configuration> 

Korzystanie logback-1.0.13 i JDK 1.6u34.

+1

Jak wygląda twój plik logback.xml? Którą wersję logback używasz? Który JDK? – Ceki

+0

Dzięki @Ceki (+1) - zapoznaj się z aktualizacjami, aby uzyskać odpowiedzi na wszystkie pytania. – IAmYourFaja

+1

Ustaw smtpAsynchroniczne wysyłanie w SMTPAppender na wartość false i zobacz, czy to robi różnicę: http://logback.qos.ch/manual/appenders.html#smtpAsynchronousSending – Ceki

Odpowiedz

7

Problem prawdopodobnie wynika z błędu w logback. Ustawienie asynchronousSending na true w SMTPAppender omija błąd (bez faktycznego jego naprawiania). Dodałem a new issue in our jira opisujący problem.

+0

Myślę, że masz na myśli, ustawianie asynchronicznego wysyłania na false! Jak napisałeś w swoim komentarzu do oryginalnego wpisu. –