September 2022 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-563: Reload4jMDCAdapter.setContextMap does not work correctly in 2.0
by QOS.CH (JIRA) 19 Sep '22

19 Sep '22

SLF4J / SLF4J-563 [Open] Reload4jMDCAdapter.setContextMap does not work correctly in 2.0 ============================== 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-563 ============================== Issue created ------------------------------ Michael Wartes created this issue on 19/Sep/22 11:02 PM Summary: Reload4jMDCAdapter.setContextMap does not work correctly in 2.0 Issue Type: Bug Affects Versions: 2.0.0 Assignee: SLF4J developers list Created: 19/Sep/22 11:02 PM Priority: Minor Reporter: Michael Wartes Description: The Reload4jMDCAdapter has been updated in 2.0 and the setContextMap method has a small but crucial logic bug in the case where the existing MDC is null. Compare [Reload4jMDCAdapter from 1.7.36|https://github.com/qos-ch/slf4j/blob/e9ee55cca93c2bf26f14482a9bdf961…] and the [Reload4jMDCAdapter from the current master branch|https://github.com/qos-ch/slf4j/blob/master/slf4j-reload4j/src/main/…] The former iterates over the context map and adds entries to the MDC like this: {code:java} org.apache.log4j.MDC.put((String) mapEntry.getKey(), mapEntry.getValue()); {code} The latter also iterates over the context map but adds entries like this: {code:java} org.apache.log4j.MDC.put(mapEntry.getKey(), mapEntry); {code} This winds up setting an MDC where the keys are mapped to the MapEntry objects of the original context map instead of the values from that map. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-562: Applications and libraries broken with SLF4J 2.x.
by QOS.CH (JIRA) 19 Sep '22

19 Sep '22

SLF4J / SLF4J-562 [Open] Applications and libraries broken with SLF4J 2.x. ============================== 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-562 ============================== Issue created ------------------------------ Garret Wilson created this issue on 19/Sep/22 6:06 PM Summary: Applications and libraries broken with SLF4J 2.x. Issue Type: Story Assignee: SLF4J developers list Components: Implementations Created: 19/Sep/22 6:06 PM Priority: Major Reporter: Garret Wilson Description: Because SLF4J 1.x is so common nowadays, there is little incentive for many to update. (I want to stress that I am a huge proponent of abandoning {{StaticLoggerBinder}} and switching to a {{ServiceLoader}} approach, so I welcome SLF4J 2.x.) In addition there may be many people reluctant to upgrade because of worries that the upgrade will break their existing code. And those worries are not unfounded! I propose that it would be valuable to keep a running list of applications and libraries that will break under SLF4J 2.x There may be a better place to maintain that list, but because I'm not aware of such a list, I'm opening this ticket. h3. Applications and Libraries Breaking with SLF4J 2.x * [Apache Spark|https://spark.apache.org/] ticket [SPARK-40489|https://issues.apache.org/jira/browse/SPARK-40489] ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-561: SLF4J 1.x to 2.x migration bridge library.
by QOS.CH (JIRA) 19 Sep '22

19 Sep '22

SLF4J / SLF4J-561 [Open] SLF4J 1.x to 2.x migration bridge library. ============================== 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-561 ============================== Issue created ------------------------------ Garret Wilson created this issue on 19/Sep/22 6:04 PM Summary: SLF4J 1.x to 2.x migration bridge library. Issue Type: New Feature Assignee: SLF4J developers list Created: 19/Sep/22 6:04 PM Priority: Major Reporter: Garret Wilson Description: Did I read somewhere that there is a SLF4J 2.x compatibility module that will provide {{StaticLoggerBinder}} to keep old applications from breaking? I thought I had read that somewhere, but I can't find it now. If there is no such thing, then I propose that a separate SLF4J 2.x library be published as a sort of "migration bridge" between SLF4J 1.x and SLF4J 2.x. It would provide a minimal {{StaticLoggerBinder}} that doesn't allow _registration_ of any modules, but would implement {{getLoggerFactory()}} to delegate to the default version. This would allow an application to manually pull in SLF4J 2.x, but still not crash when a misbehaving application such as Spark 3.3.0 tries to access {{StaticLoggerBinder}} manually. (See [SPARK-40489|https://issues.apache.org/jira/browse/SPARK-40489] This would just be a single artifact to include as a dependency to keep legacy classes from breaking. If you're not open to that suggestion, I suppose I could create such a "bridge" as part of my [Clogr|https://clogr.io/], but my first choice would be for it to be part of official SLF4J. Without such a thing, I fear SLF4J 2.x adoption could be slowed. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== 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-560 ============================== 1 comment ------------------------------ Piotr P. Karwasz on 14/Sep/22 9:42 PM For better compatibility between Log4j2 and Logback I added a lazy evaluation of the level threshold (cf. [LOG4J2 #1054|https://github.com/apache/logging-log4j2/pull/1054]). Since it's already too late to include it in Log4j2 version 2.19.0, we'll fix it in 2.19.1. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== 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-560 ============================== 1 comment ------------------------------ Ceki Gülcü on 14/Sep/22 8:27 PM [~pkarwasz] Given that in 2.0.1 {{makeLoggingEventBuilder}} always returns an enabled/active builder, you would invoke that method only when you are sure that the logger is enabled for the level in question. Otherwise, you would return {{NOPLoggingEventBuilder.singleton()}}. It is not that complicated, not complicated at all, and this the point. [~rgoers(a)apache.org] A developer of a logging implementation may presume 2.0.0 semantics, but the code might run under slf4j 2.0.1 or later. This would be mostly OK too. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== 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-560 ============================== 1 comment ------------------------------ Ralph Goers on 14/Sep/22 8:05 PM @Ceki, The makeLoggingEventBuilder method is public so you can not say it will never be called except by SubstituteLogger. Users can, and wii, call it. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== 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-560 ============================== 1 comment ------------------------------ Piotr P. Karwasz on 14/Sep/22 7:45 PM [~ceki], I understand how to implement these changes, but I don't understand their ultimate goal. If my logger has a level of {{INFO}} and I call {{makeLoggingEventBuilder(DEBUG)}} after this change I need to return {{Log4jEventBuilder(LogBuilder.NOOP)}}, which performs some work (stores parameters, message, etc.), but never logs anything. In the previous version I could return SLF4J's {{NOPLoggingEventBuilder}}. Can you provide an example where this change has a functional difference? The only application I can think of is to create a {{LoggingEventBuilder}} to use later, after the logger level changes. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== 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-560 ============================== 1 comment ------------------------------ Ceki Gülcü on 14/Sep/22 6:21 PM [~pkarwasz] As the current log4j2 implementation overrides the {{atXYZ}}, the {{makeLoggingEventBuilder}} method will not be called except in the degenerate case of {{SubstituteLogger}} if there is logging occurring during initialization. You can keep things as is, or adapt in a subsequent release of log4j2. If you adapt, you can even skip overriding {{atXYZ()}} methods in {{org.apache.logging.slf4j.Log4jLogger}} and delegate to the default implementation. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== Here's what changed in this issue in the last few minutes. There are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-560 ============================== 2 comments ------------------------------ Piotr P. Karwasz on 14/Sep/22 6:00 PM [~ceki], I don't see any advantage in returning a real builder, since the level of the builder can not be modified. Besides that the {{log4j-slf4j2-impl}} implementation currently implements {{makeLoggingEventBuilder}} as a wrapper around the Log4j2 [Logger.atLevel|https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/a…] method. If we remove the level check we'll end up with a wrapper around a NOOP {{LogBuilder}} instead of a NOOP {{LoggingEventBuilder}}, which is slightly less effective. ------------------------------ Ceki Gülcü on 14/Sep/22 6:03 PM Indeed, the {{makeLoggingEventBuilder}} is a constructor for the {{LoggingEventBuilder}} type appropriate for the implementation. The behavior is documented in the [javadocs|https://www.slf4j.org/apidocs/org/slf4j/Logger.html#atLevel-org.sl…] The log4j implementation in log4j-slf4j2 does not suffer from double checks since you override the {{atXYZ}} methods in {{org.apache.logging.slf4j.Log4jLogger}}. You could delegate to the default implementation in org.slf4j.Logger if you implement {{makeLoggingEventBuilder}} by returning an instance of {{Log4jEventBuilder}}. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-560: Clarify Logger.makeLoggingEventBuilder() method semantics
by QOS.CH (JIRA) 14 Sep '22

14 Sep '22

SLF4J / SLF4J-560 [Resolved] Clarify Logger.makeLoggingEventBuilder() method semantics ============================== 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-560 ============================== 1 comment ------------------------------ Ralph Goers on 14/Sep/22 5:25 PM IIUC, this means that if someone calls makeLoggingEventBuilder directly that the logging level will never be checked? So to do so one would have to wrap the call to makeLoggingEventBuilder in an if isEnabled block? If true I would hope this is clearly documented. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0