slf4j-api 2.0.0-alpha1 - not working about slf4j-timbre HOT 13 CLOSED

Any news on this ?

from slf4j-timbre.

org.slf4j/slf4j-api {:mvn/version "2.0.0"} was released: https://mvnrepository.com/artifact/org.slf4j/slf4j-api

Now the following also depend on it, not just com.zaxxer/HikariCP {:mvn/version "5.0.1"}:

org.slf4j/log4j-over-slf4j {:mvn/version "2.0.0"}
org.slf4j/jul-to-slf4j {:mvn/version "2.0.0"}
org.slf4j/jcl-over-slf4j {:mvn/version "2.0.0"}
org.slf4j/osgi-over-slf4j {:mvn/version "2.0.0"}

from slf4j-timbre.

from slf4j-timbre.

Am I to understand people are actually using it in the wild these days?

The only dependency of mine that uses it is com.zaxxer/HikariCP version 5.0.1.

from slf4j-timbre.

@devurandom me too.
I am doing with:
com.zaxxer/HikariCP {:mvn/version "5.0.1" :exclusions [org.slf4j/slf4j-api]}

Not sure if it will cause any error. (finger crossed).

from slf4j-timbre.

Either the 2.0.0 api is different to the 1.8 api, or it is not.

from slf4j-timbre.

In any case, it would be great if slf4j-timbre would support the 2.0.0 api.

from slf4j-timbre.

Thanks for the report, I'll look into it and also the new API

from slf4j-timbre.

thanks @rufoa
I modified the text of the original ticket.
I did do a lot of experiments with dependencies to find out what exactly is going on.
I managed to get to a stage where logging of slf4j was working WITH slf4j 2.0.0 api. I tought the culprit was day8.re-frame/tracing.

But after I wrote the ticket I could not repeat that behavior. Very bizarre

from slf4j-timbre.

I reproduced it. :-)

So I have dependencies whic bring slf4j api 2.0.0. I cannot exclude this dependencies
But I did add org.slf4j/slf4j-api {:mvn/version "1.7.30"} to my deps.edn dependencies.
This forces to use the 1.7.30 version into the classpath, even though other dependencies need a higher version.
This actually works to get slf4j logs to timbre.
However I am scared to use this in production, as I dont know if this libraries will not use functions that are not available in older apis. so I fear they might crash the app.

from slf4j-timbre.

Last time I checked (a while ago, admittedly), Ceki was still making breaking changes to the API in slf4j 2.0 alphas. Am I to understand people are actually using it in the wild these days? If so, I should prioritise adding support for it.

What was frustrating - a recurring theme with slf4j - is that the 2.0 API isn't actually compatible with the 1.7 API, despite Ceki's claims. I worry that this will necessitate two different versions of slf4j-timbre to be maintained in parallel. Hopefully I find a way to avoid this.

from slf4j-timbre.

I'd also appreciate having support for slf4j-api v2.x.x

These are my dependencies right now:

             org.slf4j/jcl-over-slf4j       {:mvn/version "2.0.5"}
             org.slf4j/jul-to-slf4j         {:mvn/version "2.0.5"}
             org.slf4j/log4j-over-slf4j     {:mvn/version "2.0.5"}

and as a workaround I'm overriding the slf4j-api transitive dependency with org.slf4j/slf4j-api {:mvn/version "1.7.36"}. It seems to work for now but I'd love to get rid of it :)

Happy to help; I can see that the problem is with the binders because they were removed from slf4j-api some time ago (e.g. StaticLoggerBinder) but I'm not sure what's meant to replace it.

from slf4j-timbre.

A lot of AWS libraries are using v2 now as well. We just noticed several apps in production stopped logging and looks like it was related to the upgrade to v2 of slf4j-api.

from slf4j-timbre.