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

[QOS.CH (JIRA)]

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

Ralph Goers commented on SLF4J-192:
-----------------------------------

@Joachim Thanks, your response to me tells me a lot:
 # Where did you "hear" that Log4 2j is both facade and implementation? This comment tells me you don't read all the comments in JIRA issues as I discussed this just yesterday. Log4j is both facade and implementation in exactly the same way that SLF4J/Logback are both facade and implementation. The Log4j API jar can be used in combination with bindings for other logging frameworks or it can be used with the Log4j implementation in exactly the same way SLF4J is the Logback API. The only confusion here is that both are part of the Log4j project and have Log4j branding.
 # The reason you don't see much discussion in LOG4J2-124 is that the issue raised by the user was valid. As you can see from the discussion, the idea that a user should not be able to shutdown logging from the public API was never even discussed. Shutdown has always been part of the Log4j implementation, just as it is in Logback. Again, LOG4J2-124 was about exposing that through the public API just as this issue is.
 # By not adding shutdown to SLF4J you are forcing users to use the Log4j API if they are using the Log4j implementation with SLF4J. In a way, I view that as a good thing. If they have to use the Log4j API for shutdown they might as well use it for everything since the Log4j API gives them the same independence from an implementation as SLF4J does. Migrating from SLF4J to Log4j pretty much just requires changing the imports and converting LogFactory to LogManager. 
 # As for your library vs application arguments, that just seems silly and arbitrary. I can appreciate that argument when it comes to manipulating the configuration since that is very much in the internals of how the logging implementation works, but shutdown is such a vague concept that it can't possibly be tied to a particular implementation. 

If I read you correctly, what you are recommending is that libraries are the only thing that should be using SLF4J. Applications should directly use the logging framework they have chosen for their implementation. 

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