On 20.03.2014 17:17, Michael Reinhold wrote:
All that being said, I'm not quite sure why you are resistant to a framework for implementing shutdown hooks. Is there a particular reason you object to the user being able to select which shutdown mechanism should be employed by Logback? I understand that you feel your solution covers most or all cases, but is it not possible that the end user of Logback may disagree and prefer to apply their own shutdown procedure or policy?
Right now what user can do inside logback shutdown hook - is just one action: calling LoggerContext.stop after stopping other app subsystems. And, if user do graceful shutdown of other subsystems in shutdown hook called "logback shutdown hook" - in fact they write own java code for application shutdown hook, but falsely name it "logback shutdown hook" This mismatch between name of logback shutdown hook and its role of application shutdown hook is the main reason why I am resistant to a creating yet one more framework for implementing shutdown hooks. Second reason: framework for implementing shutdown hooks already exists. it is Runtime.addShutdownHook() and Runtime.removeShutdownHook() methods Third reason: if implement my proposed solution in logback, the code of logback shutdown hook will look like this: public void run() { loggerContext.switchToFailSafeMode(); } If user want to call LoggerContext.stop in own application shutdown hook it still can do it in own APPLICATION shutdown hook without any problems Fourth reason: I suppose additional attribute <configuration shutdownHook="false"> (with default value "true") can be added to logback, if some user need completely turn off build-in logback shutdown hook and want to write own application shutdown hook, using already existing framework for implementing shutdown hooks from JVM. But right now this is looks like premature optimization: ======================================================================== http://c2.com/cgi/wiki?PrematureOptimization "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." ======================================================================== Fifth reason: see arguments from page https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it "Always implement things when you actually need them, never when you just foresee that you need them". "Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed". "Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards feature creep".
As a side question, how long would you estimate it would take to modify logback-core (and/or the other logback components) to implement your proposed solution?
I am not learn all details of code, but suppose that this is not very difficult task. May be few weeks, if work in spare time (need to read all sources of logback and understand internal logic).
Are you currently working on implementing this switchToFailSafe functionality
Right now - not, because I don't know if this code will be accepted or rejected, my first try was to ask about such idea - if idea accepted, as the next step I can try to write patch with this idea implementation.
or are you proposing that someone else from the logback community develop it?
I just proposing idea how to make logback graceful shutdown solution. If this idea will be accepted and approved, then next step can be done. If someone else from the logback community want to code this idea - I have nothing against this. -- Best regards, Gena