May 2017 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-410) Read logger properties from env variables
by QOS.CH (JIRA) 24 May '17

24 May '17

Krzysztof Makowski created SLF4J-410: ---------------------------------------- Summary: Read logger properties from env variables Key: SLF4J-410 URL: https://jira.qos.ch/browse/SLF4J-410 Project: SLF4J Issue Type: Improvement Affects Versions: 1.8.0-alpha2, 1.7.25 Reporter: Krzysztof Makowski Assignee: SLF4J developers list [https://github.com/qos-ch/slf4j/pull/176] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-409) Logging null messages
by QOS.CH (JIRA) 23 May '17

23 May '17

Devin Smith created SLF4J-409: --------------------------------- Summary: Logging null messages Key: SLF4J-409 URL: https://jira.qos.ch/browse/SLF4J-409 Project: SLF4J Issue Type: Bug Components: jul-to-slf4j Reporter: Devin Smith Assignee: SLF4J developers list Priority: Minor Copied from message I sent to mailing list. While searching through the logging framework(s) to see why something was being logged as it was, I came across some curious code (unrelated to my issue). [https://github.com/qos-ch/slf4j/blob/1c6cbf05e6a99a8805397d1c06008021fdc965…] While the comment seems valid, `message` is an otherwise unused local variable. If the comment is still relevant, and I'm not going crazy, I'm assuming it should instead be `record.setMessage("")`? Cheers, -Devin -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Logging null messages
by Devin Smith 23 May '17

23 May '17

While searching through the logging framework(s) to see why something was being logged as it was, I came across some curious code (unrelated to my issue). https://github.com/qos-ch/slf4j/blob/1c6cbf05e6a99a8805397d1c06008021fdc965… While the comment seems valid, `message` is an otherwise unused local variable. If the comment is still relevant, and I'm not going crazy, I'm assuming it should instead be `record.setMessage("")`? Cheers, -Devin

2 1

JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell 19 May '17

19 May '17

Hi Ceki, * JDK 9 Early Access* build 170 is available at the new location : - jdk.java.net/9/ A summary of all the changes in this build are listed here <http://download.java.net/java/jdk9/changes/jdk-9+170.html>. Changes which were introduced since the last availability email that may be of interest : * b168 - JDK-8175814: Update default HttpClient protocol version and optional request version o related to JEP 110 : HTTP/2 Client. * b169 - JDK-8178380 : Module system implementation refresh (5/2017) o changes in command line options * b170 - JDK-8177153 : LambdaMetafactory has default constructorIncompatible change, o release note: JDK-8180035 *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev mailing list *[1] * Proposal: Allow illegal reflective access by default in JDK 9 In short, the existing "big kill switch" of the `--permit-illegal-access` option [1] will become the default behavior of the JDK 9 run-time system, though without as many warnings. The current behavior of JDK 9, in which illegal reflective-access operations from code on the class path are not permitted, will become the default in a future release. Nothing will change at compile time. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

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

02 May '17

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Mariano Ruiz commented on SLF4J-371: ------------------------------------ @MiNG, the *Logger* API of both frameworks are very similar, take a look of how is defined in _Log4j2_: [https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/l…] > 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) 02 May '17

02 May '17

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] MiNG commented on SLF4J-371: ---------------------------- In the @HermanBovens case, does anyone think about how to define the method signature of `debug`, is the above code able to compile? In Java, function/method is not the first-class type, every lambda expression must be converted to a SAM interface in compile time. So, in the above case, if you want to use like this: {code:java} LOG.debug("can mix {} and {} arguments", "normal", () -> "lambda");{code} you must declare the method with fixed parameters: {code:java} void debug(String format, Object arg1, Supplier<?> arg2);{code} How about the varargs? In the varargs case the parameter type MUST declare as Object. {code:java} void debug(String format, Object... args);{code} Then, we MUST call it like this: {code:java} LOG.debug("can mix {} and {} arguments", "normal", (Supplier<?>)() -> "lambda");{code} Isn't that weird? So, I think the following method signature is more friendly to users: {code:java} // Supply the formatted string to log debug(Function<MessageFormatter, String> messageSupplier); // Invoke the log method in the closure lazily debug(Consumer<Logger> lazyLog); {code} call example: {code:java} // Supply the formatted string to log logger.debug(fmt -> "xxx" + Json.serialize(huge)); // Invoke the log method in the closure lazily logger.debug(log -> log.invoke("xxx {}", Json.serialize(huge)));{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: > ``` > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > } > ``` > 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: > ``` > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj))); > ``` > With the default method definition in the org.slf4j.Logger: > ``` > 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())); > } > } > } > ``` -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0