- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-411) EventRecodingLogger.debug(String) logs at TRACE
by QOS.CH (JIRA) 02 Jun '17

02 Jun '17

Doug Roper created SLF4J-411: -------------------------------- Summary: EventRecodingLogger.debug(String) logs at TRACE Key: SLF4J-411 URL: https://jira.qos.ch/browse/SLF4J-411 Project: SLF4J Issue Type: Bug Affects Versions: 1.8.0-alpha2 Reporter: Doug Roper Assignee: SLF4J developers list Priority: Minor [https://github.com/qos-ch/slf4j/blob/v_1.8.0-alpha2/slf4j-api/src/main/java…] \{code} public void debug(String msg) \{ recordEvent(Level.TRACE, msg, null, null); } \{code} Expected result: debug method logs at debug. Actual result: debug method logs at trace. Seems like a copy-paste bug. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[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

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

28 Apr '17

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Mariano Ruiz commented on SLF4J-371: ------------------------------------ I agree with @HermanBovens that would be better support the same API than _Log4j2_. > 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

JDK 9 EA Build 167 and JDK 8u152 build 03 are available on jdk.java.net
by Rory O'Donnell 28 Apr '17

28 Apr '17

Hi Ceki, *JDK 9 Early Access* build 167 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+167.html>. One change that maybe of interest is : * JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector [1] * * *JDK 8u152 Early Access* build 03 is available at the new location : - jdk.java.net/8/ <http://jdk.java.net/8/> More information on the change of location for Early Access builds. [2] NOTE: - Oracle's JRE and JDK Cryptographic Roadmap has been updated since last availability email [3] Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-April/005766.html [2] http://mail.openjdk.java.net/pipermail/adoption-discuss/2017-April/001610.h… [3] https://www.java.com/en/jre-jdk-cryptoroadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-408) Incorrect module name for log4j-over-slf4j
by QOS.CH (JIRA) 27 Apr '17

27 Apr '17

[ https://jira.qos.ch/browse/SLF4J-408?page=com.atlassian.jira.plugin.system.… ] Stephen Colebourne commented on SLF4J-408: ------------------------------------------ Just to note that ideally the SLF4J jars we are talking about here should not be released until the ones they are replacing have locked down their module names. The log4j v1..x package name seems to be `org.apache.log4j`, so i assume that is what will get used - http://logging.apache.org/log4j/1.2/apidocs/index.html. > Incorrect module name for log4j-over-slf4j > ------------------------------------------ > > Key: SLF4J-408 > URL: https://jira.qos.ch/browse/SLF4J-408 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.8.0-alpha1 > Reporter: Stephen Colebourne > Assignee: SLF4J developers list > Fix For: 1.8.0-alpha2 > > > I need to write this exact use case up in more detail, but see the comments section of my [naming article|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] Basically, the module name must be the same for both the real log4j and the "fake" one being supplied by this artifact. > This is because the purpose of this module is to replace the log4j one, and because two packages cannot be in the same module. It is up to the build system, ie. Maven, to select the correct artifact to fulfill a given module name. > Based on discussions on the commons-dev mailing list, I'm proposing [these as the module names|http://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3CC…] notably `org.apache.logging.log4j`. (This is based on my super-package reverse-DNS standard naming approach) > Thus the module-info.java file needs to change from a module name of `org.slf4j.log4j_over_slf4j` to `org.apache.logging.log4j`. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0