- slf4j-dev - mailman3.qos.ch

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

20 Sep '22

SLF4J / SLF4J-563 [Resolved] Reload4jMDCAdapter.setContextMap does not work correctly in 2.0 ============================== 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-563 ============================== 1 comment ------------------------------ Ceki Gülcü on 20/Sep/22 9:54 PM [~mwartes] Thank you for this report and analysis. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

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

20 Sep '22

SLF4J / SLF4J-563 [Resolved] Reload4jMDCAdapter.setContextMap does not work correctly in 2.0 ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-563 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 20/Sep/22 9:33 PM Resolution: Fixed Status: Resolved (was: In Progress) ============================== 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 adapter library.
by QOS.CH (JIRA) 20 Sep '22

20 Sep '22

SLF4J / SLF4J-561 [Resolved] SLF4J 1.x to 2.x migration adapter library. ============================== 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-561 ============================== 1 comment ------------------------------ Ceki Gülcü on 20/Sep/22 7:57 PM [~garretwilson] Thank you for letting me know. ============================== 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 adapter library.
by QOS.CH (JIRA) 20 Sep '22

20 Sep '22

SLF4J / SLF4J-561 [Resolved] SLF4J 1.x to 2.x migration adapter library. ============================== 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-561 ============================== 1 comment ------------------------------ Garret Wilson on 20/Sep/22 3:12 PM Ceki if you ever decide to mention this workaround in any documentation, note that I just released a new version with a new artifact name: {{io.clogr:slf4j1-shim:0.8.3}}. I renamed it to indicate that it doesn't require Clogr to work, and "shim" perhaps better described the role it's playing. ============================== 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 adapter library.
by QOS.CH (JIRA) 20 Sep '22

20 Sep '22

SLF4J / SLF4J-561 [Resolved] SLF4J 1.x to 2.x migration adapter library. ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-561 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 20/Sep/22 12:11 PM Resolution: Won't Fix Status: Resolved (was: Open) ============================== 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 adapter library.
by QOS.CH (JIRA) 20 Sep '22

20 Sep '22

SLF4J / SLF4J-561 [Open] SLF4J 1.x to 2.x migration adapter library. ============================== 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-561 ============================== 1 comment ------------------------------ Ceki Gülcü on 20/Sep/22 11:45 AM [~garretwilson] Thank for doing this. I should mention that SLF4J does take into account StaticLoggerBinder classes found on the class path for reasons of clarity. The solution to the migration is simple, the end-user places a logging backend on the classpath or the module path as appropriate for the version of slf4j-api in user. Also note that JMPS does not allow modules to occupy the same package space. Thus, we know for sure that StaticLoggerBinder will not work in a modular environment. ============================== 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 adapter library.
by QOS.CH (JIRA) 20 Sep '22

20 Sep '22

SLF4J / SLF4J-561 [Open] SLF4J 1.x to 2.x migration adapter library. ============================== 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-561 ============================== 1 comment ------------------------------ Garret Wilson on 20/Sep/22 5:04 AM I went ahead and implemented this with the [Clogr SLF4J 1.x Adapter|https://github.com/globalmentor/clogr/tree/master/clogr-slf4j1-adap…] which I just published to Maven Central. Now if you're running an application such as Spark which breaks SLF4J 2.x because it accesses {{StaticLoggerBinder}}, just include {{io.clogr:clogr-slf4j1-adapter:0.8.2}}, and the application will magically stop breaking: {code:xml} <dependency> <groupId>io.clogr</groupId> <artifactId>clogr-slf4j1-adapter</artifactId> <version>0.8.2</version> </dependency> {code} This way you can specify the latest SLF4J 2.x libraries as dependencies, and simply adding the {{io.clogr:clogr-slf4j1-adapter}} dependency will function as a stop-gap adapter until the application gets fixed to not rely on {{StaticLoggerBinder}}. This really belongs in the SLF4J libraries, so as soon as you implement this ticket and provide a solution as part of SLF4J, I'll remove {{io.clogr:clogr-slf4j1-adapter}} from future Clogr releases so we won't have competing workarounds. But for now it's the only thing to keep Spark and probably many other applications from breaking with SLF4J 2.x. My only other option right now would be to switch back to SLF4J 1.x, which I'm sure everyone agrees is not desirable. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[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