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

[JIRA] (SLF4J-416) Format string parameter substitution not working for single exception argument
by QOS.CH (JIRA) 25 Jul '17

25 Jul '17

[ https://jira.qos.ch/browse/SLF4J-416?page=com.atlassian.jira.plugin.system.… ] Nikolay Fedorovskikh commented on SLF4J-416: -------------------------------------------- Duplicate: LOGBACK-1183 , LOGBACK-1302 [https://github.com/qos-ch/slf4j/pull/166|https://github.com/qos-ch/slf4j/pu…] > Format string parameter substitution not working for single exception argument > ------------------------------------------------------------------------------ > > Key: SLF4J-416 > URL: https://jira.qos.ch/browse/SLF4J-416 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.25 > Reporter: Stefan Podkowinski > Assignee: SLF4J developers list > > Some logging statements will not work as intended after upgrading to 1.7.25, due to a change in the way exceptions are handled in {{MessageFormatter}}. The following test will illustrate the issue: > > {code:java} > @Test > public void testExceptionAsParameter() { > Exception e = new Exception("A terrible mistake"); > result = MessageFormatter.format("Error! {}", e).getMessage(); > assertEquals("Error! A terrible mistake", result); > } > {code} > Result: > {noformat} > org.junit.ComparisonFailure: > Expected :Error! A terrible mistake > Actual :Error! {} > {noformat} > This seems to be a regression of SLF4J-353. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-416) Format string parameter substitution not working for single exception argument
by QOS.CH (JIRA) 25 Jul '17

25 Jul '17

Stefan Podkowinski created SLF4J-416: ---------------------------------------- Summary: Format string parameter substitution not working for single exception argument Key: SLF4J-416 URL: https://jira.qos.ch/browse/SLF4J-416 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.7.25 Reporter: Stefan Podkowinski Assignee: SLF4J developers list Some logging statements will not work as intended after upgrading to 1.7.25, due to a change in the way exceptions are handled in {{MessageFormatter}}. The following test will illustrate the issue: {code:java} @Test public void testExceptionAsParameter() { Exception e = new Exception("A terrible mistake"); result = MessageFormatter.format("Error! {}", e).getMessage(); assertEquals("Error! A terrible mistake", result); } {code} Result: {noformat} org.junit.ComparisonFailure: Expected :Error! A terrible mistake Actual :Error! {} {noformat} This seems to be a regression of SLF4J-353. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-415) EventRecodingLogger.debug(String) uses wrong level
by QOS.CH (JIRA) 20 Jul '17

20 Jul '17

Alexander Yevsyukov created SLF4J-415: ----------------------------------------- Summary: EventRecodingLogger.debug(String) uses wrong level Key: SLF4J-415 URL: https://jira.qos.ch/browse/SLF4J-415 Project: SLF4J Issue Type: Bug Reporter: Alexander Yevsyukov Assignee: SLF4J developers list Priority: Minor It uses the level `TRACE`, while it should be `DEBUG` as for the rest of the `debug()` methods. A workaround would be using formatted debug output. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 9 EA Build 178 & JDK 8u152 b05 are available on jdk.java.net
by Rory O'Donnell 17 Jul '17

17 Jul '17

Hi Ceki, *JDK 9 Early Access* build 178 is available at : - 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+178.html>. Changes which were introduced since the last availability email that may be of interest : * b175 - Module system implementation refresh**(6/2017 update) * b175 - no longer has "-ea" in the version string and the system property "java version" is now simply "9" o *java -version* >java version "9" >Java(TM) SE Runtime Environment (build 9+175) >Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode) o *Bundle name changes:* e.g. jdk-9+175_linux-x86_bin.tar.gz *JDK 8u152 Early Access* build 05 is available at : - jdk.java.net/8/ <http://jdk.java.net/8/> A summary of all the changes in this build are listed here <http://download.java.net/java/jdk8u152/changes/jdk8u152-b05.html>. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-414) MDCAdapter does not handle null map
by QOS.CH (JIRA) 14 Jul '17

14 Jul '17

Dmitry created SLF4J-414: ---------------------------- Summary: MDCAdapter does not handle null map Key: SLF4J-414 URL: https://jira.qos.ch/browse/SLF4J-414 Project: SLF4J Issue Type: Bug Components: Implementations Affects Versions: 1.7.25 Reporter: Dmitry Assignee: SLF4J developers list Priority: Minor It turned out that method {{org.slf4j.impl.Log4jMDCAdapter#getCopyOfContextMap()}} may return {{null}} however {{org.slf4j.impl.Log4jMDCAdapter#setContextMap()}} does not handle this situation. That causes the Slf4j API consumer to eventually break with NPE in this code, depending on implementation / current logging backend provider: {code} Map<String, String> mcdContextMap = MDC.getCopyOfContextMap(); ... MDC.setContextMap(mcdContextMap); {code} It is expected that {{MDC.setContextMap()}} API treats {{null}} map as empty map. -- 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) 06 Jul '17

06 Jul '17

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] MiNG commented on SLF4J-371: ---------------------------- @Mariano Ruiz, I read the doc of load4j-api, we must choose one of `Supplier<T>` (lazy) or `Object` (eager), but not mixed. If the arguments contain only one lazy, the others are constants or simple variables. Using the `Supplier<T>` form will force all arguments being lazy. {code:java} LOGGER.debug("format {} {} {}", () -> "const", () -> simpleVariable, () -> Json.serialize(huge)) {code} I'm worrying about too many lambda parameters (invokedynamic) will make the logging high cost. > 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-413) Documentation - Link broken on MDC Page
by QOS.CH (JIRA) 01 Jul '17

01 Jul '17

Joerg Junge created SLF4J-413: --------------------------------- Summary: Documentation - Link broken on MDC Page Key: SLF4J-413 URL: https://jira.qos.ch/browse/SLF4J-413 Project: SLF4J Issue Type: Bug Components: Unspecified Reporter: Joerg Junge Assignee: SLF4J developers list Priority: Trivial On the Documentation Page: `Chapter 8: Mapped Diagnostic Context` [https://logback.qos.ch/manual/mdc.html] the Link to simpleMDC.xml is broken. [http://github.com/qos-ch/logback/blob/master/logback-examples/src/main/java…] Please reupload the file. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0