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

QOS.CH (JIRA) noreply-jira at qos.ch
Fri Jan 4 23:44:00 CET 2019


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

Ondrej Zizka commented on SLF4J-192:
------------------------------------

1) I, for one, am not saying that the close() functionality should be within the same scope as methods like `log.info("foo")`.

2) Imagine you have an app server that has no idea what application will come, what mix of logging facades will it use, what logger implementations will it use.
The application might have no idea what server will it run on, what logger / appender implementation will be used, and when will it be stopped, paused, or moved.
The appender has no idea what other appenders run with it and what other logging frameworks are around.
On top of that, some libraries, like HSQLDB, attempt to conform to other logging frameworks on the classpath, leading to quite messy situation.

Now imagine you write the app server's logging module and are supposed to stop the appenders - which may use a file, a websocket, a database connection, a messaging connection. These may be cached. The instance can be paused or killed any time with quite brief window to clean up (Docker / virtualization).

With proper close() method in the API, the server can call that for each supported Logging framework / facade. (Note that a facade can have an "unknown" in-house implementation, so SLF4J may be the last known point to the app server.)
Without it, you leave it up to the app authors, which goes against the purpose of app servers - to leave as much integration as possible up to the app server, and let the users focus on business logic.

People can think of logging facades as "just to do the logging itself", but that's not true - they act on the first part of the lifecycle, so they should also take responsibility for the last part of the lifecycle. That is IMO enough justification.

> 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