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

[JIRA] Updates for SLF4J-500: SLF4J LOG4J 12 Binding throws Null Pointer Exception starting with version 1.7.19
by QOS.CH (JIRA) 28 Aug '20

28 Aug '20

SLF4J / SLF4J-500 [Open] SLF4J LOG4J 12 Binding throws Null Pointer Exception starting with version 1.7.19 ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-500 ============================== 1 comment ------------------------------ Anushree on 29/Aug/20 12:35 AM I will be happy to help test the fix ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-500: SLF4J LOG4J 12 Binding throws Null Pointer Exception staring with version 1.7.19
by QOS.CH (JIRA) 24 Aug '20

24 Aug '20

SLF4J / SLF4J-500 [Open] SLF4J LOG4J 12 Binding throws Null Pointer Exception staring with version 1.7.19 ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-500 ============================== 1 comment ------------------------------ Anushree on 24/Aug/20 7:42 PM @Ceki, I am little bit confused with the update fixversion: 1.7.31... I don't see the version 1.7.31 on maven or in branch tags for slf4j. Is this issue known and fixed? Which version in maven should I use to get it? Can you help with a workaround otherwise? I am completely blocked as this jar got updated for Spark3.0 and my logging completely broke due to it. Looking forward to a response. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-500: SLF4J LOG4J 12 Binding throws Null Pointer Exception staring with version 1.7.19
by QOS.CH (JIRA) 24 Aug '20

24 Aug '20

SLF4J / SLF4J-500 [Open] SLF4J LOG4J 12 Binding throws Null Pointer Exception staring with version 1.7.19 ============================== 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-500 ============================== Issue created ------------------------------ Anushree created this issue on 24/Aug/20 8:12 AM Summary: SLF4J LOG4J 12 Binding throws Null Pointer Exception staring with version 1.7.19 Issue Type: Bug Affects Versions: 1.7.19, 1.7.20, 1.7.30 Assignee: SLF4J developers list Components: Unspecified Created: 24/Aug/20 8:12 AM Environment: I was using fluent-logger for logging and it worked well until version 1.7.18 for slf4j-log4j12. This is the offending commit introduced in 1.7.19 which was done to fix a NullPointerException. Its force initializing rootLogger to fix a NPE in multithreaded scenarios looks like. The irony is this is the commit which is causing NullPointerException for us [https://github.com/qos-ch/slf4j/commit/111b8e581e247b33bb2fe66bd0118399e0b4…] Here is the stack trace for my error: hdiuser@hn0-d0140a:/usr/hdp/4.1-0/spark2/jars$ spark-submit --version SPARK_MAJOR_VERSION is set to 2, using Spark2 Unexpected problem occured during version sanity check Reported exception: java.lang.NullPointerException at org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:267) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:126) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383) at org.fluentd.logger.sender.RawSocketSender.<clinit>(RawSocketSender.java:34) at org.fluentd.logger.FluentLoggerFactory.getLogger(FluentLoggerFactory.java:72) at org.fluentd.logger.FluentLoggerFactory.getLogger(FluentLoggerFactory.java:51) at org.fluentd.logger.FluentLogger.getLogger(FluentLogger.java:40) at com.mdsdclient.MdsLogger.<init>(Unknown Source) at com.log4jappender.common.logger.HdInsightLoggerLinux.<init>(Unknown Source) at com.log4jappender.common.logger.HdInsightLoggerFactory.getLogger(Unknown Source) at com.log4jappender.common.appendercore.AnonymizeLogAppenderCommon.getLogger(Unknown Source) at com.log4jappender.common.appendercore.AnonymizeLogAppenderCommon.<init>(Unknown Source) at com.log4jappender.AnonymizeLogAppender.activateOptions(Unknown Source) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:648) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:514) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) at org.apache.log4j.LogManager.<clinit>(LogManager.java:127) at org.slf4j.impl.Log4jLoggerFactory.<init>(Log4jLoggerFactory.java:66) at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:72) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:45) at org.apache.spark.internal.Logging$.org$apache$spark$internal$Logging$$isLog4j12(Logging.scala:222) at org.apache.spark.internal.Logging.initializeLogging(Logging.scala:127) at org.apache.spark.internal.Logging.initializeLogIfNecessary(Logging.scala:111) at org.apache.spark.internal.Logging.initializeLogIfNecessary$(Logging.scala:105) at org.apache.spark.deploy.SparkSubmit.initializeLogIfNecessary(SparkSubmit.scala:75) at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:83) at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:1007) at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:1016) at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala) Exception in thread "main" java.lang.ExceptionInInitializerError at org.fluentd.logger.FluentLoggerFactory.getLogger(FluentLoggerFactory.java:72) at org.fluentd.logger.FluentLoggerFactory.getLogger(FluentLoggerFactory.java:51) at org.fluentd.logger.FluentLogger.getLogger(FluentLogger.java:40) at com.mdsdclient.MdsLogger.<init>(Unknown Source) at com.log4jappender.common.logger.HdInsightLoggerLinux.<init>(Unknown Source) at com.log4jappender.common.logger.HdInsightLoggerFactory.getLogger(Unknown Source) at com.log4jappender.common.appendercore.AnonymizeLogAppenderCommon.getLogger(Unknown Source) at com.log4jappender.common.appendercore.AnonymizeLogAppenderCommon.<init>(Unknown Source) at com.log4jappender.AnonymizeLogAppender.activateOptions(Unknown Source) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:648) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:514) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) at org.apache.log4j.LogManager.<clinit>(LogManager.java:127) at org.slf4j.impl.Log4jLoggerFactory.<init>(Log4jLoggerFactory.java:66) at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:72) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:45) at org.apache.spark.internal.Logging$.org$apache$spark$internal$Logging$$isLog4j12(Logging.scala:222) at org.apache.spark.internal.Logging.initializeLogging(Logging.scala:127) at org.apache.spark.internal.Logging.initializeLogIfNecessary(Logging.scala:111) at org.apache.spark.internal.Logging.initializeLogIfNecessary$(Logging.scala:105) at org.apache.spark.deploy.SparkSubmit.initializeLogIfNecessary(SparkSubmit.scala:75) at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:83) at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:1007) at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:1016) at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala) Priority: Major Reporter: Anushree ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-499: Add property to log thread id
by QOS.CH (JIRA) 09 Aug '20

09 Aug '20

SLF4J / SLF4J-499 [Open] Add property to log thread id ============================== 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-499 ============================== Issue created ------------------------------ Michael Osipov created this issue on 09/Aug/20 11:54 AM Summary: Add property to log thread id Issue Type: Improvement Affects Versions: 1.7.30 Assignee: SLF4J developers list Components: slf4j-simple Created: 09/Aug/20 11:54 AM Environment: Sometimes, for debugging purposes, you need to see the thread id for chasing down deadlocks. Simple prints the thread name only. I need to run {{jps}} and {{jstack}} to figure out the id. Please add {{org.slf4j.simpleLogger.showThreadId}} which will be printed after the thread name as {{[#{id}]}}. In my usecase I use a distributed lock system which saves the node id and the thread id as lock owner. Having the thread id in the locks would make it much simpler. Priority: Major Reporter: Michael Osipov ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-498: Result of builds in Travis CI aren't integrated to PR pages
by QOS.CH (JIRA) 08 Aug '20

08 Aug '20

SLF4J / SLF4J-498 [Open] Result of builds in Travis CI aren't integrated to PR pages ============================== 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-498 ============================== Issue created ------------------------------ Kengo TODA created this issue on 09/Aug/20 1:18 AM Summary: Result of builds in Travis CI aren't integrated to PR pages Issue Type: Task Affects Versions: 2.0.0-alpha2 Assignee: SLF4J developers list Components: Unspecified Created: 09/Aug/20 1:18 AM Priority: Major Reporter: Kengo TODA Severity: normal Description: We use Travis CI to run the build to verify PRs, but it does not report the result to PR page. For instance, #232 has a checkmark for each pushed commit, but #236 doesn't have it. So it is possible that we merge PR which breaks the build without being noticed. I cannot identify the reason of this problem, so [suggest using GitHub Actions as a workaround|https://github.com/qos-ch/slf4j/pull/246] It can integrate the build result to each pushed commit without configuration. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-414: MDCAdapter does not handle null map
by QOS.CH (JIRA) 08 Aug '20

08 Aug '20

SLF4J / SLF4J-414 [Open] MDCAdapter does not handle null map ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-414 ============================== 1 comment ------------------------------ Kengo TODA on 08/Aug/20 2:49 PM I suggest another solution which keeps existing behavior, and introduces {{java.util.Optional}} which is one of modern Java best practices: https://github.com/qos-ch/slf4j/pull/245 ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

JDK 15 is now in the Initial Release Candidate Phase
by Rory O'Donnell 07 Aug '20

07 Aug '20

Hi Ceki, *Per the JDK 15 schedule , we are now in the Initial Release Candidate Phase * ***Please advise if you have any open high priority issues.*** * Schedule for JDK 15 o *2020/08/06 Initial Release Candidate* o 2020/08/20 Final Release Candidate o 2020/09/15 General Availability ** * The overall feature set is frozen. o Per the JDK Release Process [1] we now turn our focus to P1 bugs. * 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 35 *is now available at http://jdk.java.net/15 * Release notes o http://jdk.java.net/15/release-notes * Recent fixes that might be of interest o Build 34 + JDK-8246094: [macos] Sound Recording and playback is not working *JDK 16 Early Access build 9 ***is now available at http://jdk.java.net/16 * JEP Candidate o JEP 388: Windows/AArch64 Port <https://openjdk.java.net/jeps/388> * JEPs targeted to JDK 16, so far: o JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369> o JEP 357: Migrate from Mercurial to Git <https://openjdk.java.net/jeps/357> o JEP 347: Enable C++14 Language Features <https://openjdk.java.net/jeps/347> ** * Recent fixes that might be of interest o Build 9 + JDK-8243320: Add SSL root certificates to Oracle Root CA program + JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program o Build 8 + JDK-8246094: [macos] Sound Recording and playback is not working + JDK-8248655: Support supplementary characters in String case insensitive operations o Build 7 + JDK-8246032: Implementation of JEP 347: Enable C++14 Language Features *__* Rgds,Rory  [1] http://openjdk.java.net/jeps/3 -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] Updates for SLF4J-497: SLF4JLocationAwareLog avoid building message when logging level is disabled
by QOS.CH (JIRA) 06 Aug '20

06 Aug '20

SLF4J / SLF4J-497 [Open] SLF4JLocationAwareLog avoid building message when logging level is disabled ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-497 ============================== 1 comment ------------------------------ Antonio Tomac on 06/Aug/20 9:56 PM Sure, as soon I get access to printer/scanner ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-497: SLF4JLocationAwareLog avoid building message when logging level is disabled
by QOS.CH (JIRA) 06 Aug '20

06 Aug '20

SLF4J / SLF4J-497 [Open] SLF4JLocationAwareLog avoid building message when logging level is disabled ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-497 ============================== 1 comment ------------------------------ Ceki Gülcü on 06/Aug/20 5:20 PM Since the patch is more than just a few lines, may I ask you to file a [CLA|https://logback.qos.ch/cla.txt]? See also [https://github.com/qos-ch/logback/blob/master/src/main/clas/signed-clas.txt] BTW, the CLA can be sent to me directly by email. A scanned copy on two separate pages is fine but please make sure that the images render reasonably well when printed on a laser printer. Images taken by cellphone cameras often render as a large gray smudge when printed. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-497: SLF4JLocationAwareLog avoid building message when logging level is disabled
by QOS.CH (JIRA) 06 Aug '20

06 Aug '20

SLF4J / SLF4J-497 [Open] SLF4JLocationAwareLog avoid building message when logging level is disabled ============================== 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-497 ============================== Issue created ------------------------------ Antonio Tomac created this issue on 06/Aug/20 3:53 PM Summary: SLF4JLocationAwareLog avoid building message when logging level is disabled Issue Type: Improvement Affects Versions: 1.7.30 Assignee: SLF4J developers list Components: jcl-over-slf4j Created: 06/Aug/20 3:53 PM Environment: Docker Java: 1.8 Spring Boot: 2.2.5 Spring-Kafka. 2.4.4 SL4J: 1.7.30 Labels: Performance Priority: Minor Reporter: Antonio Tomac Severity: major Description: SLF4JLocationAwareLog converts input message {{*Object*}} into {{*String*}} on each invocation of logging method regardless if specific logging level is enabled. This conversion is done using String.valueOf(message). {code:java} public void trace(Object message, Throwable t) { logger.log(null, FQCN, LocationAwareLogger.TRACE_INT, String.valueOf(message), null, t); } {code} Link to source: [https://github.com/qos-ch/slf4j/blob/v_1.8.0_beta2/jcl-over-slf4j/src/main/…] Passed in message object can typically be some wrapper object around of lazy lambda to produce message. Here is example where lambda is passed from spring kafka: [https://github.com/spring-projects/spring-kafka/blob/v2.4.4.RELEASE/spring-…] Problem is that even though trace level is disabled, those messages do get constructed causing a performance penalty. In my concrete example on production, sampling showed that 20-45% of cpu time is spent here constructing message which won't even be logged. My thinking is that it should be checked if logger is enabled for specific level before doing "expensive" operation of rendering message by converting it to string. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0