April 2018 - 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.… ] 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

[JIRA] (SLF4J-434) Suggestion: Additional simplelogger.properties file
by QOS.CH (JIRA) 17 Apr '18

17 Apr '18

Joachim Durchholz created SLF4J-434: --------------------------------------- Summary: Suggestion: Additional simplelogger.properties file Key: SLF4J-434 URL: https://jira.qos.ch/browse/SLF4J-434 Project: SLF4J Issue Type: Improvement Environment: Allow an additional simplelogger.properties file. Use case: We have a simplelogger.properties in the git-managed source tree. However, we also want to have a .gitignored properties file so we can do quick local testing. Suggestion: Add configuration directive org.slf4j.simpleLogger.configFile. Includes the file, overriding the settings from the source that the configFile directive was in (simplelogger.properties or system properties, whichever may be the case). The included file must not contain another configFile directive. My status: Discussion welcome. Willing to contribute patch if so desired. Reporter: Joachim Durchholz Assignee: SLF4J developers list Priority: Minor -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-422) Have slf4j-log4j12 include extra arguments to Logger methods
by QOS.CH (JIRA) 13 Apr '18

13 Apr '18

[ https://jira.qos.ch/browse/SLF4J-422?page=com.atlassian.jira.plugin.system.… ] Eric Pabst commented on SLF4J-422: ---------------------------------- This hasn't gotten ANY attention for over 4 months! It looks like Log4J 2 doesn't have this issue at all, so it looks like it's worth switching frameworks. Its MapMessage does what I need, and JSON is directly supported rather than separate in logstash. > Have slf4j-log4j12 include extra arguments to Logger methods > ------------------------------------------------------------ > > Key: SLF4J-422 > URL: https://jira.qos.ch/browse/SLF4J-422 > Project: SLF4J > Issue Type: Improvement > Components: Implementations > Affects Versions: 1.7.22 > Environment: All > Reporter: Eric Pabst > Assignee: SLF4J developers list > > The purpose of logging to slf4j is to allow code to log information without worrying about which implementation and format will be used for actual logging. In deployed environments, we prefer JSON logging using logstash to be consumed by Splunk, which handles JSON very nicely. However, for local development and testing, we prefer text output via log4j or logback-classic. > We often want to log extra fields to show up in the JSON output such as > {{\{ "timestamp": "2017...", "message": "Event X happened", "userName": "bob", "url": "http://..."}}} > To accomplish this, we use logstash's StructuredArgument to provide extra arguments to the Logger: > {{import static net.logstash.logback.argument.StructuredArguments.keyValue;}} > {{...}} > {{ LOGGER.info("Event X happened", keyValue("userName", "bob"), keyValue("url", "http://..."));}} > We don't want to include \{}'s in the message or else it would log the username and url both in the message and as separate JSON properties. > However, when binding to slf4j-log4j12, it is logged without these extra arguments: > {{INFO 2017... Event X happened}} > It would help immensely to include these extra arguments automatically if present: > INFO 2017... Event X happened username=bob url=http://... -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 8 available
by Rory O'Donnell 12 Apr '18

12 Apr '18

Hi Ceki, **JDK 11 EA build 8, *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/8/jdk-11+8.html *Notable changes in JDK 11 EA builds since last email:* * Build 8: o If you have a library that uses the Selector API heavily then now would be a good time to test it out. [1] * Build 7 o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and will be removed in a future release. * Build 6: o JDK-8193033 : remove terminally deprecated sun.misc.Unsafe.defineClass. Users should use the public replacement `java.lang.invoke.MethodHandles.Lookup.defineClass` which was added in Java SE 9. [2] ** *SURVEY: The HotSpot Serviceability Agent (SA) *[3] * If you have used, or have (support) processes that utilize the Serviceability Agent or related APIs, then we would definitely appreciate if you would complete this survey: https://www.surveymonkey.com/r/CF3MYDL Regards, Rory [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/004964.html [2] https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lo… [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001052.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0