January 2019 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] 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)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-192: ----------------------------------- Feel free to read [https://issues.apache.org/jira/browse/LOG4J2-124] and see the justification that was used there. But if shutdown() wasn't valuable the implementation wouldn't provide it either. So it comes back to the opinion of whether the argument that people only want to use the API is valid or not. Calling shutdown() is pretty much like calling close(). Yes, you can let the OS do it but some things don't implicitly close as well as others, so virtually any application should call shutdown() if it really wants everything to be handled nicely. > 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)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-192: ----------------------------------------- The point is not that shutdown() is a problem, the point is that shutdown doesn't add value. I have yet to see a convincing counterargument to the latter point. I have seen lots of principles-based arguments, but principles need to be tied to concrete advantages/disadvantages to check that the principle really applies. IOW principles alone are a good first approximation but not enough. (At least that's my perspective. YMMV.) The application server situation might be such a use case. I don't see how shutdown() may help with that. That's probably due to a lack of familiarity with logging in application servers, not a counterargument; I would like to see how things get easier if you have a shutdown(). However, I am drawing a counterargument from the AS case: What should the logger implementation do if it gets a shutdown() call? If it's closing shared resources, this is actually NOT what you want: You don't want that a servlet shuts down container resources! If it's closing a per-servlet resource (e.g. because the servlet isn't using the container's logger but its own): then the servlet already knows that it has a specific resource, and we're back at the normal application case. I would really like to hear where my picture is incomplete. > 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)

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Be aware that this issue is currently blocked by [https://github.com/codehaus-plexus/plexus-languages/issues/23.] There are workarounds, like invoking the Javadoc tool without the maven-javadoc-plugin but obviously this is less convenient. I've reported similar bugs against maven-javadoc-plugin in recent history and they were fixed very quickly so hopefully this one will too. > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2, 1.8.0-beta3 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-192: ----------------------------------- FWIW, the Log4J 2 API added LogManager.shutdown() in the 2.6 release 2 1/2 years ago. Using the Log4j 2 API will provide you the same independence from any implementation as the Logback API (i.e SLF4J) does. > 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)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ondrej Zizka commented on SLF4J-192: ------------------------------------ The simplified view of the world, where everything is either an application or a library, keeps the real matter obfuscated. When I first commented on this issue, it was for integration within an application server, which is another level of abstraction, and is supposed to handle logging. If Slf4j had a method in an interface for the implementation to implement, it would be much less complicated to integrate. But, unfortunately, for some, world is black and white and there are just apps and libraries. > 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)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] sean commented on SLF4J-192: ---------------------------- Ha Ha. An oldie but a goodie. This JIRA has been quite the roller coaster over the years. The belligerence shown, and comments like James makes keeps me coming back for more. Keep it up guys! > 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)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] James Howe commented on SLF4J-192: ---------------------------------- The purpose of SLF4J is so libraries, not applications, can avoid using a particular impl. It is for the application, not any libraries, to decide which impl to use and when to tell it to release resources. > 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)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 04 Jan '19

04 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ondrej Zizka commented on SLF4J-192: ------------------------------------ I am not quite sure what you mean by that. So I will try to clarify: Logging implementations use resources. They manage the resources. Not an application. So they know best what to release, when asked. There is no way to ask them without using the impl API. Therefore, there should be a notification method in the generic API. If it is not, it defies the purpose of the generic API - to avoid using particualr impl. > 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)

1 0

JDK 12 Early Access build 26 & JDK 13 Early Access builds available
by Rory O'Donnell 04 Jan '19

04 Jan '19

Hi Ceki, Happy New Year! *OpenJDK builds *- JDK 12 Early Access build 26 is available at http://jdk.java.net/12/ * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes since last email o Distrust TLS server certificates anchored by Symantec Root CAs (JDK-8207258 <https://bugs.openjdk.java.net/browse/JDK-8207258>) o Customizing the generation of a PKCS12 keystore (JDK-8076190 <https://bugs.openjdk.java.net/browse/JDK-8076190>) o Compact Number Formatting Support (JDK-8177552 <https://bugs.openjdk.java.net/browse/JDK-8177552>) *OpenJDK builds *- JDK 13 - Early Access build 2 is available at http://jdk.java.net/13/ * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B1%22%3A%3A…> *jpackage EA builds* * This is an early access build of JEP 343: Packaging Tool <https://openjdk.java.net/jeps/343>, aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> *Quality Outreach report for December 2018* * The report for December 2018 is available here <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+for+D…> Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0