[
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)
_______________________________________________
slf4j-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
