April 2018 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-436) Logger name mismatch when using Spock
by QOS.CH (JIRA) 30 Apr '18

30 Apr '18

Tobias Gruetzmacher created SLF4J-436: ----------------------------------------- Summary: Logger name mismatch when using Spock Key: SLF4J-436 URL: https://jira.qos.ch/browse/SLF4J-436 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.8.0-beta2, 1.7.25 Reporter: Tobias Gruetzmacher Assignee: SLF4J developers list Priority: Minor When using the Spock Framework ([http://spockframework.org/) in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: {noformat} SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} It seems that Spock does some magic with its test classes... -- 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) 25 Apr '18

25 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Gordon commented on SLF4J-371: ------------------------------ I like @Mezītis idea. Just have logLevel(Supplier) and logLevel(Supplier, ex). Seems it would be much simpler API-wise and less confusing not having to remember that if one parameter is a Supplier they all have to be. > 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) 25 Apr '18

25 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Michael Bürkle commented on SLF4J-371: -------------------------------------- Please consider implementing this earlier. I imagine it would be rather easy to implement and it would help a great deal with cleanliness of client code. > 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-435) Minor typo in FAQ
by QOS.CH (JIRA) 23 Apr '18

23 Apr '18

Sam Mefford created SLF4J-435: --------------------------------- Summary: Minor typo in FAQ Key: SLF4J-435 URL: https://jira.qos.ch/browse/SLF4J-435 Project: SLF4J Issue Type: Bug Components: Unspecified Environment: https://www.slf4j.org/faq.html Reporter: Sam Mefford Assignee: SLF4J developers list Priority: Trivial The last character in this paragraph appears to be incorrect: {quote}SLF4J only cares about the _formatting anchor_, that is the '\{' character immediately followed by '}'. Thus, in case your message contains the '\{' or the '}' character, you do not have to do anything special unless the '}' character immediately follows '}'. {quote} Shouldn't it end with "immediately follows '\{'."? -- 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) 23 Apr '18

23 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-154: ----------------------------------------- Oh. It just occurred to me that there should not be much code bloat from LoggerFactory.getClassLogger() if the code to extract the class name is already in place for detectLoggerNameMismatch. > 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) 23 Apr '18

23 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-154: ----------------------------------------- The selling point of having a copy&paste-capable logger setup line without having to think, so you can concentrate on your class logic. The MethodHandles method sort-of achieves that (it does for a colleague who is good at remembering things, I am not so it does not work very well for me). Spotting incorrectly named loggers after the fact sort-of achieves that, too, depending on wether that error message comes as a distraction from more serious problems, or as the only, quickly-fixed problem. It's still more overhead than necessary (to be weighed against code bloat in SLF4J, but in this case I think it's worth it since SLF4J is about making logging a no-brainer). > 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.… ] 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