- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-154) Copy & paste of LoggerFactory.getLogger
by QOS.CH (JIRA) 22 Apr '18

22 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-154: ---------------------------------- Since SLF4J version 1.7.9 (released 2014-12-16): By setting the {{slf4j.detectLoggerNameMismatch}} system property to true, SLF4J can automatically [spot incorrectly named loggers|https://www.slf4j.org/codes.html#loggerNameMismatch] > Copy & paste of LoggerFactory.getLogger > --------------------------------------- > > Key: SLF4J-154 > URL: https://jira.qos.ch/browse/SLF4J-154 > Project: SLF4J > Issue Type: Bug > Components: Core API > Environment: Operating System: All > Platform: All > Reporter: Thomas Mueller > Assignee: SLF4J developers list > Attachments: clipboard.png > > > This is a feature request. > Currently, when I create a new logger in a class, I copy & paste the following line from another class: > private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); > Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: > private static Logger log = LoggerFactory.getCallerClassLogger(); > This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: > getCallerClassLogger() { > return getLogger(new Error().getStackTrace()[1].getClassName()); > } > There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- 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) 22 Apr '18

22 Apr '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] James Howe commented on SLF4J-192: ---------------------------------- In most cases there is no code with a direct dependency on the backend. Isn't that the entire point of slf4j? The backend in use can be changed via just the classpath and nothing needs to know what it actually is. Except in this case where the application is trying to shutdown without losing any log events. > 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) 22 Apr '18

22 Apr '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-192: ----------------------------------- FWIW, the Log4j 2 API has had LogManager.shutdown() for 2 years now. There is no reason the API has to know what the backend does when that method is called. SLF4J could add a new Interface to the SPI and only do something if it detects the backend has implemented it. > 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-154) Copy & paste of LoggerFactory.getLogger
by QOS.CH (JIRA) 22 Apr '18

22 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-154: ----------------------------------- FWIW, the Log4j 2 API has supported this for almost 5 years now as LogManager.getLogger(); > Copy & paste of LoggerFactory.getLogger > --------------------------------------- > > Key: SLF4J-154 > URL: https://jira.qos.ch/browse/SLF4J-154 > Project: SLF4J > Issue Type: Bug > Components: Core API > Environment: Operating System: All > Platform: All > Reporter: Thomas Mueller > Assignee: SLF4J developers list > Attachments: clipboard.png > > > This is a feature request. > Currently, when I create a new logger in a class, I copy & paste the following line from another class: > private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); > Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: > private static Logger log = LoggerFactory.getCallerClassLogger(); > This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: > getCallerClassLogger() { > return getLogger(new Error().getStackTrace()[1].getClassName()); > } > There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-154) Copy & paste of LoggerFactory.getLogger
by QOS.CH (JIRA) 22 Apr '18

22 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-154: ----------------------------------------- While the MethodHandles approach is copy&paste-compatible, it is pretty unintuitive (method handles for getting a class object wtf?), and it's sort of going out of its way to be unavailable to IDE autocompletion. For that reason, I'd still like SLF4J to offer a static LoggerFactory.getClassLogger() function. It would require stack inspection to work under JDK 1.5, but I wouldn't care because that overhead would be dwarved by class loading&linking overhead anyway. > Copy & paste of LoggerFactory.getLogger > --------------------------------------- > > Key: SLF4J-154 > URL: https://jira.qos.ch/browse/SLF4J-154 > Project: SLF4J > Issue Type: Bug > Components: Core API > Environment: Operating System: All > Platform: All > Reporter: Thomas Mueller > Assignee: SLF4J developers list > Attachments: clipboard.png > > > This is a feature request. > Currently, when I create a new logger in a class, I copy & paste the following line from another class: > private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); > Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: > private static Logger log = LoggerFactory.getCallerClassLogger(); > This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: > getCallerClassLogger() { > return getLogger(new Error().getStackTrace()[1].getClassName()); > } > There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- 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) 22 Apr '18

22 Apr '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-192: ----------------------------------------- The code that has the direct dependency on the backend also knows why the backend needs a flush, and how to do it, so it can simply call that code wherever it would to the requested slf4j flush() call. If the place that would do the flush() doesn't and shouldn't know about the backend in use, let the logger initialization framework supply a Runner, or a Consumer<ShutdownInfo>, or whatever java.util.function interface is best. Flushing the backend is a real need, but SLF4J isn't the right messenger to relay the signal. > 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-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 17 Apr '18

17 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Jānis commented on SLF4J-371: ----------------------------- Thanks, didn't know about "java.text.MessageFormat.format", good to know, will use it! > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 17 Apr '18

17 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-371: ----------------------------------------- @[~Mezītis] Java cannot use variable names from inside strings for security reasons, so that isn't going to change. However, it does have string interpolation in a more sane format than what String.format() offers: import static java.text.MessageFormat.format; ... log.debug(() -> format("Incorrect value: \{0} in column: \{1}", value, column) > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-433) slf4j backend configuration errors are not fatal
by QOS.CH (JIRA) 17 Apr '18

17 Apr '18

[ https://jira.qos.ch/browse/SLF4J-433?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-433: ----------------------------------------- In my book, it is okay to know the backend in the module that has the explicit dependency on Logback, and if that code is concentrated in one class. If you agree, you can just check Logback's health directly. If Logback does not offer an API to do that (I haven't checked), you could write a "canary Appender" that does not emit anything, just records whether it got log message, and check whether the messages arrive (you'll have a direct dependency on the canary there, which in turn has a direct dependency on Logback, so you're indeed stuck with a Logback dependency). WRT reconfiguration, IIRC Logback simply sticks with the previous configuration if the new configuration is faulty. Which may or may not be what you want, depending on the exact reasons why you consider a broken log configuration fatal. I tend to construct my log configuration by putting a fallback Logback configuration into the classpath, and load that first. I can test that configuration and be confident that the software will always start with a minimum viable log configuration. This happens during start-up, i.e. in main() or in the webapp's initialization hooks. I want logging to be initialized as early as possible, which sort-of automatically concentrates the dependency in one place where it is easily managed. > slf4j backend configuration errors are not fatal > ------------------------------------------------ > > Key: SLF4J-433 > URL: https://jira.qos.ch/browse/SLF4J-433 > Project: SLF4J > Issue Type: Improvement > Reporter: Thorbjørn Ravn Andersen > Assignee: SLF4J developers list > > I know that a great deal of care has been put into making slf4j invisible to the application doing the logging. This includes configuration errors being transparent and all. > We consider logging framework configuration errors fatal, and would like a mechanism that can tell the main application that the logging framework is broken so it can do an emergency shutdown. Our usecase is at application start up (first logging statement) but the generic case would probably be after each (re)configuration. > As we by default cannot specify this through the configuration file, this probably needs to be triggered by a system property. I'd really prefer a solution which does not "know in application code" that the slf4j backend is logback. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 17 Apr '18

17 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Jānis commented on SLF4J-371: ----------------------------- Also it would be nice if we could use something like this: {code:java} log.debug(() -> "key:"+key+" value:"+value );{code} And hopefully java at some point add proper string interpolation support, and than we could use something like: {code:java} log.debug(() -> "key:$key value:$value" );{code} Pros: 1. Only one lambda is used. > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0