[slf4j-dev] [JIRA] Updates for SLF4J-561: SLF4J 1.x to 2.x migration adapter library.

[QOS.CH (JIRA)]

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-adapter], 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)