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

JDK 12 enters Rampdown Phase Two
by Rory O'Donnell 21 Jan '19

21 Jan '19

Hi Ceki, **OpenJDK builds *- JDK 12 Early Access build 28 **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase Two. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o Per the JDK Release Process [3] we now turn our focusto P1 and P2 bugs. **OpenJDK builds *- JDK 13 Early Access build 4 is **now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Release Notes: o http://jdk.java.net/13/release-notes * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B3%22%3A%3A…> Blog Updates from Java SE Product Management since last email. * Oracle Java SE Releases FAQ [3] * Oracle Java SE Support Roadmap [4] Rgds,Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002537.html [3] https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq [4] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-293) Output of Profiler.toString() isn't indented correctly
by QOS.CH (JIRA) 18 Jan '19

18 Jan '19

[ https://jira.qos.ch/browse/SLF4J-293?page=com.atlassian.jira.plugin.system.… ] Nicolò Chieffo commented on SLF4J-293: -------------------------------------- attached possible patch, > Output of Profiler.toString() isn't indented correctly > ------------------------------------------------------ > > Key: SLF4J-293 > URL: https://jira.qos.ch/browse/SLF4J-293 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.7.x > Environment: Operating System: Windows XP > Platform: PC > Reporter: Stefan Orth > Assignee: SLF4J developers list > Attachments: example.txt, Profiler.java.patch > > > Hi, Profiler headline is on the third level (and maybe further levels?) not correctly indented. An example is attached. > Keep up the good work and thanks for creating slf4j! -- 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) 18 Jan '19

18 Jan '19

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- MJAVADOC-563 is fixed in 3.1.0 which should be released "soon" :) > 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-437) Create a BOM POM
by QOS.CH (JIRA) 17 Jan '19

17 Jan '19

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Jesse Farinacci commented on SLF4J-437: --------------------------------------- Would a PR be accepted? > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- 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) 09 Jan '19

09 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Andrea Santi commented on SLF4J-192: ------------------------------------ Sorry for the super-late reply. @Joachim on the one side I can understand your concerns: it is important to understand what SLF4J is and this should drive the development. I always imagined it as a "wall" separating a common API from a concrete logging framework. Final objective, make it easy to switch between from one logging implementation to another: the only effort required is change the jars and the configuration file of the concrete logging implementation. So, from my point of view SLF4J should contains all the functionalities required to manage logging in my application, even startup/shutdown (i.e. I don't want to look at the other part of the wall in my code). I believe that the homepage of SLF4J is saying more or less the same thing {{"The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks, such as java.util.logging, logback and log4j. SLF4J allows the end-user to plug in the desired logging framework at _deployment_ time. *"*}} The majority of logging frameworks now provide methods for shutdown. I don't really see the problem of widening the interface given the purpose I believe SLF4J should have. But again, this is just my opinion. The opinions that matter here are the ones of the *maintainers and of the majority of the users.* @Ondrej, @sean and all the others: I totally get your points and I'm 100% with you. In my concrete case I have an appender that is creating a thread to send logs to an external log collector system. This thread need to be shutted down to avoid a memory leak. So, I really believe that this capability should be in SLF4J or otherwise I will have to "look at the other part of the wall" and call *LogManager.shutdown()* of the underlying logging framework in my code. Like Onrej I'm not in rethorical excercise. So I'm going to phase out from this discussion as well. I understand that this is a decision that need to be done by SLF4J mantainers. I can make my own decisions and decide if is still worth using SLF4J or not. cheers! > 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) 09 Jan '19

09 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ondrej Zizka commented on SLF4J-192: ------------------------------------ I am phasing out from this discussion. There are relevant practical reasons to have shutdown in the API. There are also irrelevant academic reasons to keep the purity of the facade concept. It is up to Slf4j maintainers, which I assume [~toolforger] is not, so I see no point in further rhetorical excercise. Thanks. > 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) 05 Jan '19

05 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-192: ----------------------------------------- @Ralph Your assumptions about me are mostly wrong, which is the usual risk when arguing ad hominem in the Internet. "Silly and arbitrary" - well, you're not giving any arguments beyond that value judgement, so I find it difficult to clear up any misunderstandings on your and my side. I find your post generally pretty vague - lots of belittling, very little arguments. You may have valid reasons to reject my points, but I don't see any arguments that I can respond to, so continuing at that level is pointless and I'll stop. But I will continue to call shenanigans at purely abstract arguments, unless it's clear that and in what way the abstractions apply. > 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) 05 Jan '19

05 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-192: ----------------------------------- @Joachim Thanks, your response to me tells me a lot: # Where did you "hear" that Log4 2j is both facade and implementation? This comment tells me you don't read all the comments in JIRA issues as I discussed this just yesterday. Log4j is both facade and implementation in exactly the same way that SLF4J/Logback are both facade and implementation. The Log4j API jar can be used in combination with bindings for other logging frameworks or it can be used with the Log4j implementation in exactly the same way SLF4J is the Logback API. The only confusion here is that both are part of the Log4j project and have Log4j branding. # The reason you don't see much discussion in LOG4J2-124 is that the issue raised by the user was valid. As you can see from the discussion, the idea that a user should not be able to shutdown logging from the public API was never even discussed. Shutdown has always been part of the Log4j implementation, just as it is in Logback. Again, LOG4J2-124 was about exposing that through the public API just as this issue is. # By not adding shutdown to SLF4J you are forcing users to use the Log4j API if they are using the Log4j implementation with SLF4J. In a way, I view that as a good thing. If they have to use the Log4j API for shutdown they might as well use it for everything since the Log4j API gives them the same independence from an implementation as SLF4J does. Migrating from SLF4J to Log4j pretty much just requires changing the imports and converting LogFactory to LogManager. # As for your library vs application arguments, that just seems silly and arbitrary. I can appreciate that argument when it comes to manipulating the configuration since that is very much in the internals of how the logging implementation works, but shutdown is such a vague concept that it can't possibly be tied to a particular implementation. If I read you correctly, what you are recommending is that libraries are the only thing that should be using SLF4J. Applications should directly use the logging framework they have chosen for their implementation. > 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) 05 Jan '19

05 Jan '19

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

1 0

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

05 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-192: ----------------------------------------- @Ralph Unfortunately, [https://issues.apache.org/jira/browse/LOG4J2-124] does not really argue why shutdown() would be a good idea. The discussion quickly diverges into the appropriate place to implement it. I hear that Log4J is both facade and implementation. If that's true, pointing at Log4J and saying that it has shutdown() isn't enough of an argument anyway: You also need to argue that it's in the facade part of Log4J, and that the association to that part was the correct decision. Feel free to complete that argument, but for now I'm staying unconcinved. > 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