slf4j-timbre
slf4j-timbre copied to clipboard
slf4j-api 2.0.0-alpha1 - not working
clojure -X:deps tree
com.fzakaria/slf4j-timbre 0.3.21
X com.taoensso/timbre 4.10.0 :use-top
X org.slf4j/slf4j-api 1.7.30 :superseded
info.sunng/ring-jetty9-adapter 0.15.1
. ring/ring-servlet 1.9.2
X ring/ring-core 1.9.2 :use-top
. org.eclipse.jetty/jetty-server 10.0.2
. org.eclipse.jetty.toolchain/jetty-servlet-api 4.0.6
. org.eclipse.jetty/jetty-http 10.0.2
. org.eclipse.jetty/jetty-util 10.0.2
. org.slf4j/slf4j-api 2.0.0-alpha1
. org.eclipse.jetty/jetty-io 10.0.2
. org.slf4j/slf4j-api 2.0.0-alpha1
. org.eclipse.jetty/jetty-io 10.0.2
. org.eclipse.jetty/jetty-util 10.0.2
. org.slf4j/slf4j-api 2.0.0-alpha1
. org.slf4j/slf4j-api 2.0.0-alpha1 :newer-version
log output in app
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to 1.8.
SLF4J: Ignoring binding found at [jar:file:/home/andreas/.m2/repository/com/fzakaria/slf4j-timbre/0.3.21/slf4j-timbre-0.3.21.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
Either the 2.0.0 api is different to the 1.8 api, or it is not.
In any case, it would be great if slf4j-timbre would support the 2.0.0 api.
Thanks for the report, I'll look into it and also the new API
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
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.
Any news on this ?
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.
I see a lot of apps / libraries that use the 2.0 version slf4j api. So it would be great to be able to pipe their logs to timbre.
I agree tha you will most likely need a different artefact.
On Sun, May 22, 2022, 20:20 Rufus @.***> wrote:
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 https://github.com/qos-ch/slf4j/pull/190/#issuecomment-495959349 - is that the 2.0 API isn't actually compatible https://jira.qos.ch/browse/SLF4J-495?focusedCommentId=20714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-20714 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.
— Reply to this email directly, view it on GitHub https://github.com/fzakaria/slf4j-timbre/issues/45#issuecomment-1134060315, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACS2CGUC5RRS5JZXVUSC3M3VLLMNFANCNFSM47YVHKEA . You are receiving this because you authored the thread.Message ID: @.***>
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.
See-also: https://github.com/brettwooldridge/HikariCP/issues/2078
@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).
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"}
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.
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.