[slf4j-dev] [JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders

QOS.CH (JIRA) noreply-jira at qos.ch
Wed Jan 9 18:58:00 CET 2019


    [ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19408#comment-19408 ] 

Andrea Santi commented on SLF4J-192:
------------------------------------

Sorry for the super-late reply.

 

@Joachim on the one side I can understand your concerns: it is important to understand what SLF4J is and this should drive the development. I always imagined it as a "wall" separating a common API from a concrete logging framework. Final objective, make it easy to switch between from one logging implementation to another: the only effort required is change the jars and the configuration file of the concrete logging implementation. So, from my point of view SLF4J should contains all the functionalities required to manage logging in my application, even startup/shutdown (i.e. I don't want to look at the other part of the wall in my code). I believe that the homepage of SLF4J is saying more or less the same thing

{{"The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks, such as java.util.logging, logback and log4j. SLF4J allows the end-user to plug in the desired logging framework at _deployment_ time. *"*}}

The majority of logging frameworks now provide methods for shutdown. I don't really see the problem of widening the interface given the purpose I believe SLF4J should have. But again, this is just my opinion. The opinions that matter here are the ones of the *maintainers and of the majority of the users.*

@Ondrej, @sean and all the others: I totally get your points and I'm 100% with you. In my concrete case I have an appender that is creating a thread to send logs to an external log collector system. This thread need to be shutted down to avoid a memory leak. So, I really believe that this capability should be in SLF4J or otherwise I will have to "look at the other part of the wall" and call *LogManager.shutdown()* of the underlying logging framework in my code.

 

 

Like Onrej I'm not in rethorical excercise. So I'm going to phase out from this discussion as well. I understand that this is a decision that need to be done by SLF4J mantainers. I can make my own decisions and decide if is still worth using SLF4J or not.

 

cheers!

> Need ability to shutdown loggers and flush appenders
> ----------------------------------------------------
>
>                 Key: SLF4J-192
>                 URL: https://jira.qos.ch/browse/SLF4J-192
>             Project: SLF4J
>          Issue Type: Improvement
>          Components: Core API
>    Affects Versions: 1.6.x
>         Environment: Operating System: All
> Platform: All
>            Reporter: Michael Schall
>            Assignee: SLF4J developers list
>
> There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed.
> Should ILoggerFactory have a shutdown or stop method?  It could shutdown whatever logging back end I'm using?
> For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown();
> For logback it would call - loggerContext.stop()
> Other back ends - ???
> This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events.
> Discussion about this is happening on the user list at -
> http://www.qos.ch/pipermail/logback-user/2010-September/001816.html



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)


More information about the slf4j-dev mailing list