June 2020 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-494: slf4j introduces the log4j version of 1.2.17. There is a security vulnerability. The security vulnerability CVE numbers are CVE-2019-17571 and CVE-2020-9488. Please fix it.
by QOS.CH (JIRA) 29 Jun '20

29 Jun '20

SLF4J / SLF4J-494 [Open] slf4j introduces the log4j version of 1.2.17. There is a security vulnerability. The security vulnerability CVE numbers are CVE-2019-17571 and CVE-2020-9488. Please fix it. ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-494 ============================== Issue created ------------------------------ zhongyuqin created this issue on 29/Jun/20 8:57 AM Summary: slf4j introduces the log4j version of 1.2.17. There is a security vulnerability. The security vulnerability CVE numbers are CVE-2019-17571 and CVE-2020-9488. Please fix it. Issue Type: Bug Affects Versions: 1.7.30 Assignee: SLF4J developers list Components: Core API Created: 29/Jun/20 8:57 AM Priority: Blocker Reporter: zhongyuqin ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Re: [slf4j-dev] SLF4J-168 Numeric Values in MDC for SLF4J 2.0
by Anastas Stoyanovsky 25 Jun '20

25 Jun '20

1 0

Re: [slf4j-dev] SLF4J-168 Numeric Values in MDC for SLF4J 2.0
by Anastas Stoyanovsky 25 Jun '20

25 Jun '20

1 0

[JIRA] Updates for SLF4J-493: Lambda expression call with log4j logs the wrong line number
by QOS.CH (JIRA) 25 Jun '20

25 Jun '20

SLF4J / SLF4J-493 [Open] Lambda expression call with log4j logs the wrong line number ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-493 ============================== Issue created ------------------------------ Daniel Gray created this issue on 25/Jun/20 2:25 PM Summary: Lambda expression call with log4j logs the wrong line number Issue Type: Bug Assignee: SLF4J developers list Created: 25/Jun/20 2:25 PM Environment: Any, with the latest (2.0.0-alpha1) version of SLF4J. Priority: Major Reporter: Daniel Gray Description: The logger output the wrong log line (120 for INFO, 117 for DEBUG, etc.) instead of the line in the program that generated the log, when running against a Log4J backend. This causes potential confusion when a person debugging something is reading the logs as the line numbers are wrong! I know that it is SLF4J that is doing something wrong instead of Log4J, because running just with Log4J does not manifest the same behavior. I have prepared 2 simple CLI apps to show the correct behavior (with only Log4J) and the incorrect behavior (with SLF4J). Both are using the exact same configuration (log4j2.properties). The repositories of these sample projects are: Good behavior with log4j: [https://github.com/danielthegray/log4j-nobugsample] Wrong behavior with slf4j: [https://github.com/danielthegray/slf4j-bugsample] Both of the programs run with a simple "./gradlew run" so it should be straightforward to reproduce. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

Jira is down! + SLF4J logging wrong line numbers with lambda parameters
by Daniel Gray 25 Jun '20

25 Jun '20

Hello all, I am writing to first of all notify you that your Jira instance is not behaving properly and is throwing 500 errors when I try to list the issues under the SLF4J project. When doing it from an anonymous account, it just shows an error, but after signing up, it just shows a popup saying that an error has occurred. Therefore, I am unable to file a bug report through the conventional path. The bug consists of SLF4J causing Log4J to log the wrong line line number when using a lambda parameter. How do I know that it is an SLF4J bug? I have prepared two sample projects, one only with Log4J, using lambda parameters, where the line numbers are correct, and an SLF4J project (using the exact same configuration) where the lambda reference causes a wrong line number to be used. The two sample projects can be found here: Good behavior with log4j: https://github.com/danielthegray/log4j-nobugsample Wrong behavior with slf4j: https://github.com/danielthegray/slf4j-bugsample I am happy to be guided towards what the best next step is to getting this fixed. Both of the programs run with a simple "./gradlew run" so it should be straightforward to reproduce. Kind regards, Daniel

2 1

JDK 15 is in Rampdown Phase One
by Rory O'Donnell 22 Jun '20

22 Jun '20

Hi Ceki, *Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] * *Please advise if you find any issues while testing the latest Early Access builds. * * Schedule for JDK 15 o *2020/06/11 Rampdown Phase One* o 2020/07/16 Rampdown Phase Two o 2020/08/06 Initial Release Candidate o 2020/08/20 Final Release Candidate o 2020/09/15 General Availability * Features included in JDK 15: o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) <http://openjdk.java.net/jeps/339> o JEP 360: Sealed Classes (Preview) <http://openjdk.java.net/jeps/360> o JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371> o JEP 372: Remove the Nashorn JavaScript Engine <http://openjdk.java.net/jeps/372> o JEP 373: Reimplement the Legacy DatagramSocket API <https://openjdk.java.net/jeps/373> o JEP 374: Disable and Deprecate Biased Locking <http://openjdk.java.net/jeps/374> o JEP 375: Pattern Matching for instanceof (Second Preview) <https://openjdk.java.net/jeps/375> o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector <http://openjdk.java.net/jeps/377> o JEP 378: Text Blocks <http://openjdk.java.net/jeps/378> o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector <https://openjdk.java.net/jeps/379> o JEP 381: Remove the Solaris and SPARC Ports <https://openjdk.java.net/jeps/381> o JEP 383: Foreign-Memory Access API (Second Incubator) <https://openjdk.java.net/jeps/383> o JEP 384: Records (Second Preview) <https://openjdk.java.net/jeps/384> o JEP 385: Deprecate RMI Activation for Removal <https://openjdk.java.net/jeps/385> *JDK 15 **Early Access build 28 **is available**at : - jdk.java.net/15/* These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception**Release notes * Release notes o http://jdk.java.net/15/release-notes * Recent fixes that might be of interest o Build 27 + JDK-8233215: jpackage doesn't allow enough flexibility for file type binding + JDK-8244582: Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option + JDK-8245068: Implement Deprecation of RMI Activation + JDK-8246770: Atomic::add() with 64 bit value fails to link on 32-bit platforms # Reported by JaCoCo o Build 26 + JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 # Reported by Apache Tomcat o Build 25 + JDK-8206925: Support the certificate_authorities extension + JDK-8239480: Support for CLDR version 37 + JDK-8243925: Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows) *JDK 16 Early Access build 2 ****is available**at : - jdk.java.net/16/* These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception.* * *_Survey on _**_jinfo, jmap, jstack serviceability tools in JDK:_ * * Oracle is considering deprecation and (eventual) removal of 3 JDK tools - jinfo, jmap, jstack. * The Survey Link <https://www.questionpro.com/a/TakeSurvey?tt=n%2BDcx/aY3aA%3D> will remain open through July 15 2020. Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004401.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (SLF4J-489) Add java.util.logging.config.class for SLF4JBridgeHandler
by QOS.CH (JIRA) 05 Jun '20

05 Jun '20

[ https://jira.qos.ch/browse/SLF4J-489?page=com.atlassian.jira.plugin.system.… ] Martin Vanek commented on SLF4J-489: ------------------------------------ Refreshed PR [https://github.com/qos-ch/slf4j/pull/237] > Add java.util.logging.config.class for SLF4JBridgeHandler > --------------------------------------------------------- > > Key: SLF4J-489 > URL: https://jira.qos.ch/browse/SLF4J-489 > Project: SLF4J > Issue Type: Improvement > Components: jul-to-slf4j > Affects Versions: 1.7.29 > Reporter: Martin Vanek > Assignee: SLF4J developers list > Priority: Minor > Fix For: 2.0.0-alpha2, 1.7.30 > > > Add JUL java.util.logging.config.class implementation to be able to easily use code-less SLF4JBridgeHandler initialization using JVM parameter > -Djava.util.logging.config.class=org.slf4j.bridge.SLF4JBridgeHandler.Initializer > It simply adds org.slf4j.bridge.SLF4JBridgeHandler as root j.u.l Logger handler. No need for logging.properties and java.util.logging.config.file which can't be taken from classpath and must be filesystem path. > See [https://docs.oracle.com/javase/10/docs/api/java/util/logging/LogManager.html] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-489) Add java.util.logging.config.class for SLF4JBridgeHandler
by QOS.CH (JIRA) 05 Jun '20

05 Jun '20

[ https://jira.qos.ch/browse/SLF4J-489?page=com.atlassian.jira.plugin.system.… ] Martin Vanek commented on SLF4J-489: ------------------------------------ PR exists since 2016 [https://github.com/qos-ch/slf4j/pull/57] and just needs resync with master which I'll do soon > Add java.util.logging.config.class for SLF4JBridgeHandler > --------------------------------------------------------- > > Key: SLF4J-489 > URL: https://jira.qos.ch/browse/SLF4J-489 > Project: SLF4J > Issue Type: Improvement > Components: jul-to-slf4j > Affects Versions: 1.7.29 > Reporter: Martin Vanek > Assignee: SLF4J developers list > Priority: Minor > Fix For: 2.0.0-alpha2, 1.7.30 > > > Add JUL java.util.logging.config.class implementation to be able to easily exploit code-less SLF4JBridgeHandler initialization using JVM parameter > -Djava.util.logging.config.class=org.slf4j.bridge.SLF4JBridgeHandler.Initializer -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-489) Add java.util.logging.config.class for SLF4JBridgeHandler
by QOS.CH (JIRA) 04 Jun '20

04 Jun '20

Martin Vanek created SLF4J-489: ---------------------------------- Summary: Add java.util.logging.config.class for SLF4JBridgeHandler Key: SLF4J-489 URL: https://jira.qos.ch/browse/SLF4J-489 Project: SLF4J Issue Type: Improvement Components: jul-to-slf4j Affects Versions: 1.7.29 Reporter: Martin Vanek Assignee: SLF4J developers list Priority: Minor PR exists since 2016 [https://github.com/qos-ch/slf4j/pull/57] and just needs resync with master which I'll do soon -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0