[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=19403#comment-19403 ] 

Joachim Durchholz commented on SLF4J-192:
-----------------------------------------

@Ondrej You paint a situation where neither the application server nor the application know which facade is being used.

That's obviously never going to happen.
Servers will provide a facade _and_ implementation for the convenience of the applications, so they will know how to shut down the implementation.
Some applications will decide to use their own implementation, and they will use a facade so that any libraries that they use will be happy. Again, the application knows what implementation to shut down.
Using SLF4J doesn't seem to provide a benefit for these scenarios.

The appenders and libraries seem to be covered: They don't need to call shutdown() by themselves, they are closed down by the application. Actually they shouldn't bother at all, because they aren't notified of any global lifecycle; they are supposed to close things when they are told to, and of course the application knows when to do that.

Docher and other virtualization frameworks: Now indeed the container may have to talk with applications when it is about to be moved. They shouldn't have to, but we all know that things often aren't as seamless in practice as they are in theory.
However, the application needs to be told anyway. It may have to safeguard its own database connection, fill up caches, and whatever else it wants to do. Actually you do not WANT to shutdown and restart loggers in that scenario (if moving needs special precautions, then that's exactly the time when you want the most intense logging so at least you can do a post-mortem if things fail). So I don't see a real use case here - if you need to shut down logging you have a misdesign.
The same goes for the container. If it needs to shut down logging, it's doing it wrong.
Now I know that sometimes you're forced to to it wrong. But then we are still back at square one: If something special needs to be done, whoever is managing the backend needs to be notified and deal with that. A humble shutdown() method isn't going to work anyway, you'd need a restart() method. And this method would do nothing but route things back to the implementation, to places that the logging management module already knew and already was depending on. All you achieve with shutdown here is, again, routing an existing dependency through SLF4J, just to arrive at the same point where it was started.

I think we're in disagreement about what the purpose of a logging facade is, or maybe that of SLF4J (it is a good thing if we can agree that the disagreement is here).
For application libraries, it's essential. They cannot know what backend is being used, so they MUST use a facade. They don't deal with logging setup and shutdown, so they don't need shutdown().
For the code that sets up and tears down the loggers, appenders, database connections and whatnot, SLF4J doesn't give it any advantage. That code is dealing with the specifics of a particular logging setup anyway, routing shutdown activities through SLF4J would be just silly. That's what I have been having in mind; from this perspective, shutdown() is just a burden with zero benefit.
Now I can imagine that there are libraries for setting up and tearing down loggers, managing logging configuration. Logging can be pretty complicated, so there's value in such libraries. (I haven't seen such a library, but I can imagine that they are part of application server code.) However, in this use case, I'm seriously questioning that SLF4J is the right library to have this; we don't need just shutdown(), we also need configure(), start(), restart().
Am I overlooking a scenario?

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