fzakaria / slf4j-timbre Goto Github PK

SLF4J binding for Clojure's Timbre

License: Eclipse Public License 1.0

Clojure 95.04% Java 4.96%

slf4j-timbre's Introduction

slf4j-timbre

This project is an SLF4J binding (interface) for Clojure's Timbre logging framework. It allows Timbre to receive log messages emitted by code designed to use SLF4J.

If your Clojure project depends on a Java library which speaks SLF4J – such as Jetty – but you'd rather all its logs went to your existing Timbre setup instead of needing a separate SLF4J configuration, then this project is for you.

Usage

Simply add slf4j-timbre to your project dependencies:

That is all!

Other logging frameworks

In addition to SLF4J, slf4j-timbre can receive logs from projects designed around Log4j, java.util.logging (JUL), and Apache Commons Logging (JCL). To do this, add the corresponding dependency to your project:

[org.slf4j/log4j-over-slf4j "1.7.36"]
[org.slf4j/jul-to-slf4j "1.7.36"]
[org.slf4j/jcl-over-slf4j "1.7.36"]

Logs from Log4j/JUL/JCL projects are then forwarded to SLF4J, which in turn forwards them to Timbre.

Troubleshooting

slf4j-timbre requires [org.slf4j/slf4j-api "1.7.14"] or later, and [com.taoensso/timbre "4.3.0-RC1"] or later.

If you are having problems, ensure your project or its (transitive) dependencies are not pulling in earlier versions of these libraries, as these may shadow the required newer versions. You can check for this using lein deps :tree.

For other problems please open an issue on GitHub!

License

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.

slf4j-timbre's People

Contributors

Stargazers

Watchers

slf4j-timbre's Issues

Noisy Netty logs show up after adopting this library

Hi there,

this library works as intended. Kudos!

However I noticed this relatively minor nuisance at startup (e.g. lein repl):

18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.logging.InternalLoggerFactory:71] - Using SLF4J as the default logging framework
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:76] - java.nio.Buffer.address: available
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:76] - sun.misc.Unsafe.theUnsafe: available
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:71] - sun.misc.Unsafe.copyMemory: available
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:76] - java.nio.Bits.unaligned: true
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - Java version: 8
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.noUnsafe: false
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - sun.misc.Unsafe: available
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.noJavassist: false
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:71] - Javassist: available
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.tmpdir: /var/folders/2j/336sh1s13jv80nmvg2y5gyc80000gp/T (java.io.tmpdir)
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.bitMode: 64 (sun.arch.data.model)
18-12-22 01:10:57 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.noPreferDirect: false
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.logging.InternalLoggerFactory:71] - Using SLF4J as the default logging framework
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:76] - java.nio.Buffer.address: available
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:76] - sun.misc.Unsafe.theUnsafe: available
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:71] - sun.misc.Unsafe.copyMemory: available
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent0:76] - java.nio.Bits.unaligned: true
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - Java version: 8
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.noUnsafe: false
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - sun.misc.Unsafe: available
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.noJavassist: false
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:71] - Javassist: available
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.tmpdir: /var/folders/2j/336sh1s13jv80nmvg2y5gyc80000gp/T (java.io.tmpdir)
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.bitMode: 64 (sun.arch.data.model)
18-12-22 01:11:33 UnknownHost DEBUG [io.netty.util.internal.PlatformDependent:76] - -Dio.netty.noPreferDirect: false

...those lines didn't show up before slf4j-timbre adoption. From what I can see, Netty has the following static code which will run merely by being imported: https://github.com/netty/netty/blob/6464c98743779778e52db59522f269bfe47a46af/common/src/main/java/io/netty/util/internal/PlatformDependent.java#L92

So, in the average project that uses both Netty and Timbre, it's much more likely that Netty will be imported before Timbre is setup, which would be the place to silence this annoyance.

Is this a known scenario?

I tried solving it with :jvm-opts ["-Dorg.slf4j.simpleLogger.defaultLogLevel=WARN"], no luck. Another one was (-> (Logger/getLogger "io.netty.util.internal.PlatformDependent") (.setLevel Level/OFF)) in user.clj.

Thanks - Victor

context is not passed to output-fn

Hi,

I'm currently facing an issue with custom context, that is declared via timbre/with-context, not being delivered to the middleware and output-fn, when using the clojure.tools.logging adapter.

Steps to reproduce

Project dependencies

[com.taoensso/timbre "4.10.0"]
[com.fzakaria/slf4j-timbre "0.3.10"]
[org.apache.logging.log4j/log4j-1.2-api "2.11.0"]
[org.slf4j/log4j-over-slf4j "1.7.25"]
[org.slf4j/jul-to-slf4j "1.7.25"]
[org.slf4j/jcl-over-slf4j "1.7.25"]

Snippet

(do
  (require '[taoensso.timbre :as log])
  (require '[clojure.tools.logging :as clj-log])
  (require '[clojure.pprint :as pprint])

  (defn print-context [data]
    (pprint/pprint (:context data))
    data)

  (log/swap-config! assoc :middleware [print-context])

  (log/with-context {:hello "world"}
    (log/info "Log with Timbre")
    (clj-log/info "Log with Clojure Tools")))

Output

{:hello "world"}
18-06-28 08:28:21 my-machine INFO [user:13] - Log with Timbre
nil
18-06-28 08:28:21 my-machine INFO [user:286] - Log with Clojure Tools

Expected behavior

The custom application context should be supplied regardless of the log api that was used.

Origin of log entries misreported

I just got this in my logs:
16-Jan-14 00:30:13 rufus-laptop.home DEBUG [slf4j-timbre.adapter] - Entry count for : https://api.twitter.com:443 : 0

The real origin is netty but it is being misreported as coming from slf4j-timbre.adapter itself.

Need to investigate why

update to latest Timbre

It looks like the 4.1.4 version of Timbre relies on an old version of encore that's still built against tools.reader 0.9.2. The tools.reader API changed in 0.10.0 and since slf4j-timbre uses :gen-class it ends up compiling the old versions of the libraries into the jar. See some details on the side effects in this issue taoensso/sente#181

Ideally, if there was a way to not include Timbre and its related classes in the jar that would be the best solution I think. Perhaps it's possible to treat them as provided or limit AOT to only slf4j-timbre namespaces explicitly.

binding with slf4j-api does not work

I'm using slf4j-timbre with slf4j-api as suggested in the README.md,
however when I try to build - the default implementation kicks in (NOP)
and an error is thrown:

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:/Users/daniel/.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.

several slf4j-apis' version I tried: 1.7.14, 1.7.32, 1.8.0-alpha0 - but all of them has returned the same exception.

os: mac-os with intel chip
sdk: I tired with several open-sdk's: 1.8, 11, 17.
The code was built using Polylith architecture .

anyone has a suggestion?
Thanks for the help

Cannot use with jboss owing to nil assertion on arg-array

When trying to use with immutant, directing logs to slf4j and then slf4j-timbre, it silently fails and starts printing default output to stdout. After a fair amount of assistance from @tobias, he discovered that the logging subsystem init was failing because of this assertion: https://github.com/fzakaria/slf4j-timbre/tree/master/src/slf4j_timbre/adapter.clj#L95 and then defaulting to something else. Removing this assertion correctly directs logs to timbre as desired.

Opening as an issue instead of a PR because I'm not sure if that assertion is important for other use cases.

SLF4j actual binding gets unset when importing dgraph4j

https://github.com/dgraph-io/dgraph4j

Essentially without this project in deps.edn:

SLF4J: Actual binding is of type [com.github.fzakaria.slf4j.timbre.TimbreLoggerFactory]

adding it results in

 SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]

using these dependencies

        io.dgraph/dgraph4j {:mvn/version "2.0.2"}
        com.taoensso/timbre {:mvn/version "4.10.0"}
        com.fzakaria/slf4j-timbre {:mvn/version "0.3.19"}
        org.slf4j/slf4j-api {:mvn/version "1.7.21"}

Are you able to reproduce and/or know the cause of this?

NoClassDefFoundError attempting to log using 0.3.18

When upgrading to 0.3.18 of slf4j-timbre, I'm getting the following stack trace:

java.lang.NoClassDefFoundError: taoensso/timbre$may_log_QMARK_
    at slf4j_timbre.adapter$_isDebugEnabled.invokeStatic(adapter.clj:159)
    at slf4j_timbre.adapter$_isDebugEnabled.invoke(adapter.clj:158)

These are my relevant dependencies:

[com.taoensso/timbre "4.10.0"]
[org.slf4j/log4j-over-slf4j "1.7.30"]
[org.slf4j/jul-to-slf4j "1.7.30"]
[org.slf4j/jcl-over-slf4j "1.7.30"]

Verified using lein deps :tree that [com.taoensso/timbre "4.10.0"] is indeed the version on the classpath.

timbre 6.0 support

Timbre 6.0 is out and added this issue to track support for that.
We are in the process of upgrading to see how it goes.

This comes after #42 .

Does not respect TIMBRE_LEVEL compile time var

In a project with no timbre config, but only a TIMBRE_LEVEL var, timbre respects the level but other java libraries using slf-4j do not.

slf4j-timbre causes mysterious failure due to encore and reader

I got bit by this as well. It actually took me hours to try to track it down, and I never did figure it out. But thankfully someone finally did:

http://yogthos.net/posts/2015-12-26-AOTGotchas.html

I suppose maybe the library instead of :aot :all could exclude some namespaces from AOT? Or is this impossible to fix?

First line of log does not comply to timbre settings

Hi, I'm running jetty with timbre for logging and slf4j-timbre to be able to handle other libraries' messages.
Versions:

[com.taoensso/timbre "4.5.1"]
[com.fzakaria/slf4j-timbre "0.3.2"]
[org.slf4j/jul-to-slf4j  "1.7.21"]
[org.slf4j/jcl-over-slf4j "1.7.21"]
[org.slf4j/log4j-over-slf4j "1.7.21"]
[ring/ring-jetty-adapter "1.3.2"]

It works fine - except for the very first log line, which completely ignores my timbre settings (see first line below).

16-07-15 14:54:16 jenglot DEBUG [org.eclipse.jetty.util.log:89] - Logging to com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter@7c20cdd0 via org.eclipse.jetty.util.log.Slf4jLog
16-07-15 14:54:16,767 INFO [org.eclipse.jetty.server.Server:74] - jetty-7.6.13.v20130916
16-07-15 14:54:16,786 INFO [org.eclipse.jetty.server.AbstractConnector:74] - Started [email protected]:3001

My main function goes like this:

(defn -main
  [& args]
  ;; set up log format
  (log/merge-config! log-config)

  ;; https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions
  (Thread/setDefaultUncaughtExceptionHandler
   (reify Thread$UncaughtExceptionHandler
     (uncaughtException [_ thread ex]
       (log/error ex))))

  (jetty/run-jetty app {:port 3001}))

So you see, in theory the very first line merges my timbre config.
I can work around it (by doing some logstash foo) but I thought I'd let you know, since it looks like a slf4j-timbre output

Wrong number of args (3) passed to: adapter/-debug

With

   [com.zaxxer/HikariCP "2.4.1"]
  [com.fzakaria/slf4j-timbre "0.2"]

Hikari throws this error:

                                  hikari-cp.core/make-datasource                          core.clj:  138
                       com.zaxxer.hikari.HikariDataSource.<init>             HikariDataSource.java:   69
                         com.zaxxer.hikari.HikariConfig.validate                 HikariConfig.java:  782
                 com.zaxxer.hikari.HikariConfig.logConfiguration                 HikariConfig.java:  826
      com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter.debug          TimbreLoggerAdapter.java:   63
com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapterHelper.debug                                        
                                                             ...                                        
clojure.lang.ArityException: Wrong number of args (3) passed to: adapter/-debug

The relevant line in Hikari appears to be:
https://github.com/brettwooldridge/HikariCP/blob/dev/src/main/java/com/zaxxer/hikari/HikariConfig.java#L839

Which is apparently not compatible with this:
https://github.com/fzakaria/slf4j-timbre/blob/master/src/main/java/com/github/fzakaria/slf4j/timbre/TimbreLoggerAdapter.java#L63

Not sure who is in the right here (hikari or slf4j-timbre), but any help resolving this would be appreciated. Thanks!

mongodb log problem

I've recently been trying to get slf4j-timbre to work with mongodb logs, but getting an error that seems to be introduced only when I add slf4j-timbre as a dependency.

I've been closely following the changes made in the last few days, like updating the README to include the three 1.7.14 version dependencies, so I think everything is OK with having the right dependencies.

I'm using a standalone MongoDB as the datasource for the application, and normally (without slf4j-timbre) it it successfully returns a server from the ReadPreferenceServerSelector query (stacktrace attached: no-slf4j-timbre.log).

However, when I add slf4j-timbre as a dependency in project.clj (and that's the only change), it fails on the first DB operation, which I can't explain, but it looks like it may be due to the mongodb logging event being a warning, which timbre-adapter tries to wrap, but fails for some reason.

add-slf4j-timbre.txt
no-slf4j-timbre.txt

timbre 5.0 support

https://github.com/ptaoussanis/timbre/releases/tag/v5.0.0

doesn't work with latest version of timbre 4.3.1

push_listings_index | 16-03-16 20:56:06 565cd3e3f185 INFO [push-listings-index.main:44] - Created new listings index push_listings_index | Exception in thread "main" java.lang.IllegalStateException: Attempting to call unbound fn: #'taoensso.timbre/log1-fn, compiling:(/tmp/form-init816281410483448011.clj:1:72) push_listings_index | at clojure.lang.Compiler.load(Compiler.java:7391) push_listings_index | at clojure.lang.Compiler.loadFile(Compiler.java:7317) push_listings_index | at clojure.main$load_script.invokeStatic(main.clj:275) push_listings_index | at clojure.main$init_opt.invokeStatic(main.clj:277) push_listings_index | at clojure.main$init_opt.invoke(main.clj:277) push_listings_index | at clojure.main$initialize.invokeStatic(main.clj:308) push_listings_index | at clojure.main$null_opt.invokeStatic(main.clj:342) push_listings_index | at clojure.main$null_opt.invoke(main.clj:339) push_listings_index | at clojure.main$main.invokeStatic(main.clj:421) push_listings_index | at clojure.main$main.doInvoke(main.clj:384) push_listings_index | at clojure.lang.RestFn.invoke(RestFn.java:421) push_listings_index | at clojure.lang.Var.invoke(Var.java:383) push_listings_index | at clojure.lang.AFn.applyToHelper(AFn.java:156) push_listings_index | at clojure.lang.Var.applyTo(Var.java:700) push_listings_index | at clojure.main.main(main.java:37) push_listings_index | Caused by: java.lang.IllegalStateException: Attempting to call unbound fn: #'taoensso.timbre/log1-fn push_listings_index | at clojure.lang.Var$Unbound.throwArity(Var.java:43) push_listings_index | at clojure.lang.AFn.invoke(AFn.java:62) push_listings_index | at slf4j_timbre.adapter$_info$inner__2062__auto____2103.invoke(adapter.clj:46) push_listings_index | at clojure.lang.AFn.applyToHelper(AFn.java:154) push_listings_index | at clojure.lang.AFn.applyTo(AFn.java:144) push_listings_index | at clojure.core$apply.invokeStatic(core.clj:646) push_listings_index | at clojure.core$apply.invoke(core.clj:641) push_listings_index | at slf4j_timbre.adapter$_info.doInvoke(adapter.clj:46) push_listings_index | at clojure.lang.RestFn.invoke(RestFn.java:423) push_listings_index | at com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter.info(Unknown Source) push_listings_index | at com.mongodb.diagnostics.logging.SLF4JLogger.info(SLF4JLogger.java:71) push_listings_index | at com.mongodb.connection.SingleServerCluster.<init>(SingleServerCluster.java:45) push_listings_index | at com.mongodb.connection.DefaultClusterFactory.create(DefaultClusterFactory.java:85) push_listings_index | at com.mongodb.Mongo.createCluster(Mongo.java:683) push_listings_index | at com.mongodb.Mongo.createCluster(Mongo.java:669) push_listings_index | at com.mongodb.Mongo.createCluster(Mongo.java:643) push_listings_index | at com.mongodb.Mongo.<init>(Mongo.java:290) push_listings_index | at com.mongodb.MongoClient.<init>(MongoClient.java:268) push_listings_index | at monger.core$connect_via_uri.invokeStatic(core.clj:195) push_listings_index | at monger.core$connect_via_uri.invoke(core.clj:195) push_listings_index | at push_listings_index.mongo$oplog_HEAD_ts_BANG_.invokeStatic(mongo.clj:43) push_listings_index | at push_listings_index.mongo$oplog_HEAD_ts_BANG_.invoke(mongo.clj:41) push_listings_index | at push_listings_index.main$_main.invokeStatic(main.clj:50) push_listings_index | at push_listings_index.main$_main.doInvoke(main.clj:40) push_listings_index | at clojure.lang.RestFn.invoke(RestFn.java:397) push_listings_index | at clojure.lang.Var.invoke(Var.java:375) push_listings_index | at user$eval5.invokeStatic(form-init816281410483448011.clj:1) push_listings_index | at user$eval5.invoke(form-init816281410483448011.clj:1) push_listings_index | at clojure.lang.Compiler.eval(Compiler.java:6927) push_listings_index | at clojure.lang.Compiler.eval(Compiler.java:6917) push_listings_index | at clojure.lang.Compiler.load(Compiler.java:7379) push_listings_index | ... 14 more

When I reverted to timbre 4.2.1 it fixed the problem

Use of clojure.string without require

https://github.com/fzakaria/slf4j-timbre/blob/master/src/slf4j_timbre/adapter.clj#L25

This happens to be okay, but may not always be depending on how other libraries decide to perform requires.

Remove Compiled classes from the distributed jar

Hi,

Thank you for building this adaptor :)

We started to encounter some issues related to dependencies and it seems slf4j-timbre is released with compiled classes in the JAR (~278Kb).

  0 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/
  1332 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_isErrorEnabled.class
   966 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$define_methods$iter__2498__2504.class
   903 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_error_Marker_String_Object$fn__2574.class
   815 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_trace_String_Object$fn__3242.class
  4701 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_debug_Marker_String_Object.class
  3985 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_warn_Marker_String.class
   822 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_error_Marker_String_Object$fn__2576.class
  1339 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/static_logger_binder$_init.class
  1323 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/static_marker_binder$_init.class
   830 Tue Jun 27 19:37:36 BST 2017 slf4j_timbre/adapter$_error_Marker_String_Object_LT__GT_$fn__2654.class

It can causes compatibility issues and weird behaviour ( possibly https://dev.clojure.org/jira/browse/CLJ-1886 ?)

Would it be possible to release slf4j-timbre without the compiled java classes, just the source code ?

Blacklisting Log4J namespaces does not work

Hello @fzakaria,
I added all the deps you suggest to the my project but when I specify (either at app bootstrap or at runtime):

{:level :debug
             :ns-blacklist ["com.zaxxer.hikari.*"]}

I can still see the DEBUG logs for that namespace (which is recurring, so very annoying I would say 😄).

If this issue is not strictly related to slf4j-timbre please let me know and I will close it immediately ok?
Thank you!

Could not find artifact

When I include the dependency like so:

:aliases {:test      {:extra-paths ["src/test"]
                       :extra-deps  {fulcrologic/fulcro-spec      {:mvn/version "3.1.8"}
                                     com.taoensso/timbre          {:mvn/version "5.1.0"}
                                     coorg.slf4j/log4j-over-slf4j {:mvn/version "1.7.30"}   ; auto sends log4j to slf4j
                                     coorg.slf4j/jul-to-slf4j     {:mvn/version "1.7.30"}   ; auto sends java.util.logging to slf4j
                                     coorg.slf4j/jcl-over-slf4j   {:mvn/version "1.7.30"} ; auto-sends java.common.logging to slf4j
                                     cocom.fzakaria/slf4j-timbre  {:mvn/version "0.3.20"}}} ; hooks slf4j to timbre

Then run clj -Atest and get:

$ clj -Atest
Error building classpath. Could not find artifact cocom.fzakaria:slf4j-timbre:jar:0.3.20 in central (https://repo1.maven.org/maven2/)

Wonder what I am missing

slf4j-timbre compiled with JDK 1.8

Is there any reason why this has been released with JDK 1.8?

I'm getting following

Exception in thread "main" java.lang.UnsupportedClassVersionError: org/slf4j/impl/StaticLoggerBinder : Unsupported major.minor version 52.0, compiling:(core.clj:268:1)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3628)
at clojure.lang.Compiler$DefExpr.eval(Compiler.java:439)
at clojure.lang.Compiler.eval(Compiler.java:6787)

It's coming from HOME/.m2/repository/com/fzakaria/slf4j-timbre/0.2.1/slf4j-timbre-0.2.1.jar in my classpath.

$ javap -cp . -verbose org.slf4j.impl.StaticLoggerBinder | grep major
  major version: 52

I'm using 1.7 still for my projects, and can't move to 1.8, this is the only lib causing errors.

Also, I can't seem to override this because org.slf4j.impl.StaticLoggerBinder is included directly in the jar (as opposed to by dependency), then even adding a specific 'org.slf4j/slf4j-simple "1.7.13"' in my dependency is being overridden by slf4j-timbre.

Is there another solution to this I'm missing?

can't silence logs in tests

Hi, I have a library that wraps caffeine (which uses java.util.logging). And I am trying to silence the logs during tests.

Added [org.slf4j/jul-to-slf4j "1.7.30"] [com.fzakaria/slf4j-timbre "0.3.19"] to project.clj under :profiles/:dev/:dependencies and my deps are:

[com.fzakaria/slf4j-timbre "0.3.19" :scope "test"]
...
[com.taoensso/timbre "4.10.0" :scope "test"]
...
 [org.slf4j/jul-to-slf4j "1.7.30" :scope "test"]

on my tests I have added a fixture:

(defn configure-logger [test-fn]
  (let [initial-config timbre/*config*]
    (timbre/merge-config! {:appenders {:spit {:enabled? false}}})
    ;; (prn timbre/*config*)
    (test-fn)
    (timbre/set-config! initial-config)))

(use-fixtures :each configure-logger)

also, tried the same during compile time ((timbre/merge-config! {:appenders {:spit {:enabled? false}}}))

But I can still see some logging generated as a result of the unit tests:

WARNING: Exception thrown during refresh
java.util.concurrent.CompletionException: clojure.lang.ExceptionInfo: fail {}
        at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
        at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
        at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1592)
        at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1582)
        at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
        at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
        at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
        at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: clojure.lang.ExceptionInfo: fail {}
        at cloffeine.core_test$fn__4845$fn__4846.invoke(core_test.clj:82)
        at cloffeine.common$reify_cache_loader$reify__464.load(common.clj:59)
        at com.github.benmanes.caffeine.cache.CacheLoader.reload(CacheLoader.java:166)
        at com.github.benmanes.caffeine.cache.CacheLoader.lambda$asyncReload$2(CacheLoader.java:190)
        at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590)
        ... 5 more

Choice of two errors, no errors is not an option

With this:

;; ...
                  [com.fzakaria/slf4j-timbre "0.3.13"]
                   [com.taoensso/timbre "4.10.0"]
                     [org.slf4j/slf4j-log4j12 "1.7.26"]

I get

log4j:WARN No appenders could be found for logger (org.apache.http.client.protocol.RequestAddCookies).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

OK... if I add this, though:

;; ...
                [com.fzakaria/slf4j-timbre "0.3.13"]
                   [com.taoensso/timbre "4.10.0"]
                     [org.slf4j/slf4j-log4j12 "1.7.26"]
                 [org.slf4j/log4j-over-slf4j "1.7.14"]

Then the whole compile fails, with:

							 PatternLayout.TTCC_CONVERSION_PATTERN);
							              ^
  symbol:   variable TTCC_CONVERSION_PATTERN
  location: class PatternLayout

From a .java source file vendored dependency that does its own log4j logging.

In both cases, lein tree shows that this does include

 [log4j "1.2.17"]

as a transitive dependency.

I could edit the java dep but will probably just limp along with the apache error instead.

Incompatable w/ slf4j-jdk-platform-logging 2.0

Thanks for all your work on this library and the upgrade to slf4j 2.0!

I've noticed that using slf4j-timbre with a library that depends on slf4j-jdk-platform-logging will result in the JVM exiting after attempting to call functions that don't exist in adapter.clj.

Specifically it looks like the adapter is expected to provide a -isEnabledForLevel method as well as handle a call within performLog to a new method -makeLoggingEventBuilder.

I played with implementing the methods locally but wanted to confirm if this is actually something that adapter.clj should handle. Similarly, is there a reference to any other methods that 2.0 is expecting the adapter to implement that are also missing? Alternatively, perhaps this is an issue with the SLF4JPlatformLogger implementation using non-standard methods?

Again, thanks for all the work in this and sorry I am not familiar enough with the SLF4J ecosystem / 2.0 upgrade to know what the right course of action is.

Default log level does not match default timbre log level

The code here clearly shows this:

slf4j-timbre/src/slf4j_timbre/factory.clj

Lines 12 to 22 in b077afc

 (defn -init 

 [] 

 (let [default-config (var-get (resolve 'taoensso.timbre/example-config))] 

 (when (and (compare-and-set! bootstrapped? false true) (= timbre/*config* default-config)) 

 (let [level (or (System/getProperty "TIMBRE_LEVEL") (System/getenv "TIMBRE_LEVEL") ":info")] 

 (reset! slf4j-timbre.adapter/override-level (keyword (subs level 1)))) 

 (add-watch #'timbre/*config* ::on-first-config 

 (fn [_ _ _ _] 

 (reset! slf4j-timbre.adapter/override-level nil) 

 (remove-watch #'timbre/*config* ::on-first-config))))) 

 [[] (atom {})])

This caused me a lot of problem and valuable time trying to understand why the default setup was not logging at :debug level which is the advertised default for timbre

is the `jul` in `[org.slf4j/jul-over-slf4j "1.7.12"]` a typo?

I'm getting this when following instructions in README to add deps to project:

Could not find artifact org.slf4j:jul-over-slf4j:jar:1.7.12 in central (https://repo1.maven.org/maven2/) Could not find artifact org.slf4j:jul-over-slf4j:jar:1.7.12 in clojars (https://clojars.org/repo/) This could be due to a typo in :dependencies or network issues.

I also couldn't find much mention of that library anywhere via google.

... I was wondering if [org.slf4j/jul-over-slf4j "1.7.12"] is a typo of [org.slf4j/jcl-over-slf4j "1.7.12"] beneath it ?

If not, this dependency is broken.

configuration from file

Hi
I find it very difficult to load the configuration from a config file. Probably because the configuration needs to be compiled, right?
Is there a way of doing it?
Thanks
MK

Including `slf4j-timbre` in Timbre core's unit tests?

Hi there!

What would you think of perhaps having a unit test in Timbre's core for slf4j-timbre? Might be a good way to help ensure that I don't accidentally break anything on your side when releasing new versions of Timbre.

If you agree this might make sense, could I maybe impose on you to submit a small PR against Timbre? I'm not too familiar with slf4j-timbre internals or config - so you'd probably be in a better position than me to choose a useful test.

Otherwise I'll try take a look at this myself next time I'm doing batched work on Timbre.

Thanks so much for all your work on slf4j-timbre!

Cheers :-)

java exception's stack trace not displayed

In java code I have the following:

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public final class Boom {

  private static final Log LOG = LogFactory.getLog(Boom.class);

  public static void boom() throws Exception {
    try {
      throw new Exception("BoomException");
    } catch (Exception e) {
      LOG.error("Got an exception: ", e);
    }
  }
}

When running this without slf4j-timbre I get the full stack trace in the logs, but with slf4j-timbre, I only get the first line:

17-01-20 12:02:50 host ERROR [Boom:209] - Got an exception:

I tried adding a timbre middleware to inspect the data and it seems the error object is missing altogether.
I've created a repo with a minimal example displaying the issue: https://github.com/geekingfrog/slf4j-timbre-issue

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.

High log volume can cause serious performance degredation

When using this library in a project, an upstream library was using apache.http.*, which has significant trace logging. It looks like on every log message this library calls .getStackTrace, which causes a really significant spike in CPU usage, even if our log level isn't at trace.

timbre 4.5.0 api breakage

This commit (included in v.4.5.0 tag): taoensso/timbre@e5b95cb seems to break sl4j-timbre with this:

Caused by: clojure.lang.ArityException: Wrong number of args (9) passed to: timbre/-log!
        at clojure.lang.AFn.throwArity(AFn.java:429)
        at clojure.lang.AFn.invoke(AFn.java:67)
        at slf4j_timbre.adapter$_info_String_Object.doInvoke(adapter.clj:81)
        at clojure.lang.RestFn.invoke(RestFn.java:439)
        at com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter.info(Unknown Source)

Pinning to v4.4.0 of timbre resolves the issue. I might be able to contribute a PR later, but this is a heads up to anyone else playing along at home.

Exception with Timbre v6.3.1

Hi,

Clojure CLI version 1.11.1.1435

openjdk 21.0.1 2023-10-17 LTS
OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (build 21.0.1+12-LTS, mixed mode, sharing)

com.fzakaria/slf4j-timbre {:mvn/version "0.4.1"}
com.taoensso/timbre {:mvn/version "6.3.1"}

When starting an application using these dependencies, the following is thrown:

2024-01-08T13:29:01 Exception in thread "main" java.lang.NoSuchFieldError: Class taoensso.timbre__init does not have member field 'clojure.lang.ILookupThunk __thunk__0__'
2024-01-08T13:29:01 	at taoensso.timbre__init.load(Unknown Source)
2024-01-08T13:29:01 	at taoensso.timbre__init.<clinit>(Unknown Source)
2024-01-08T13:29:01 	at java.base/java.lang.Class.forName0(Native Method)
2024-01-08T13:29:01 	at java.base/java.lang.Class.forName(Unknown Source)
2024-01-08T13:29:01 	at java.base/java.lang.Class.forName(Unknown Source)
2024-01-08T13:29:01 	at clojure.lang.RT.classForName(RT.java:2209)
2024-01-08T13:29:01 	at clojure.lang.RT.classForName(RT.java:2218)
2024-01-08T13:29:01 	at clojure.lang.RT.loadClassForName(RT.java:2237)
2024-01-08T13:29:01 	at clojure.lang.RT.load(RT.java:449)
2024-01-08T13:29:01 	at clojure.lang.RT.load(RT.java:424)
2024-01-08T13:29:01 	at clojure.core$load$fn__6908.invoke(core.clj:6161)
2024-01-08T13:29:01 	at clojure.core$load.invokeStatic(core.clj:6160)
2024-01-08T13:29:01 	at clojure.core$load.doInvoke(core.clj:6144)
2024-01-08T13:29:01 	at clojure.lang.RestFn.invoke(RestFn.java:408)
2024-01-08T13:29:01 	at clojure.core$load_one.invokeStatic(core.clj:5933)
2024-01-08T13:29:01 	at clojure.core$load_one.invoke(core.clj:5928)
2024-01-08T13:29:01 	at clojure.core$load_lib$fn__6850.invoke(core.clj:5975)
2024-01-08T13:29:01 	at clojure.core$load_lib.invokeStatic(core.clj:5974)
2024-01-08T13:29:01 	at clojure.core$load_lib.doInvoke(core.clj:5953)
2024-01-08T13:29:01 	at clojure.lang.RestFn.applyTo(RestFn.java:142)
2024-01-08T13:29:01 	at clojure.core$apply.invokeStatic(core.clj:669)
2024-01-08T13:29:01 	at clojure.core$load_libs.invokeStatic(core.clj:6016)
2024-01-08T13:29:01 	at clojure.core$load_libs.doInvoke(core.clj:6000)
2024-01-08T13:29:01 	at clojure.lang.RestFn.applyTo(RestFn.java:137)
2024-01-08T13:29:01 	at clojure.core$apply.invokeStatic(core.clj:669)
2024-01-08T13:29:01 	at clojure.core$require.invokeStatic(core.clj:6038)
2024-01-08T13:29:01 	at clojure.core$require.doInvoke(core.clj:6038)
2024-01-08T13:29:01 	at clojure.lang.RestFn.invoke(RestFn.java:421)
2024-01-08T13:29:01 	at slf4j_timbre.adapter$loading__6789__auto____171.invoke(adapter.clj:1)
2024-01-08T13:29:01 	at slf4j_timbre.adapter__init.load(Unknown Source)
2024-01-08T13:29:01 	at slf4j_timbre.adapter__init.<clinit>(Unknown Source)
2024-01-08T13:29:01 	at java.base/java.lang.Class.forName0(Native Method)
...
...
...

Reverting to com.taoensso/timbre {:mvn/version "6.2.2"} does not produce an error.

Do let me know if you require any further information.

Thank you.

-=david=-

Regression for timbre v6

On v5, this line of code (https://github.com/fzakaria/slf4j-timbre/blob/master/src/slf4j_timbre/factory.clj#L15) outputs:

(require '[taoensso.timbre :as timbre])
=> nil
(= timbre/*config* (var-get (resolve 'taoensso.timbre/example-config)))
=> true
timbre/*config*
=>
{:min-level :debug,
 :ns-filter #{"*"},
 :middleware [],
 :timestamp-opts {:pattern :iso8601, :locale :jvm-default, :timezone :utc},
 :output-fn #object[taoensso.timbre$default_output_fn 0x2907b20b "taoensso.timbre$default_output_fn@2907b20b"],
 :appenders {:println {:enabled? true,
                       :async? false,
                       :min-level nil,
                       :rate-limit nil,
                       :output-fn :inherit,
                       :fn #object[taoensso.timbre.appenders.core$println_appender$fn__5755
                                   0x320defc8
                                   "taoensso.timbre.appenders.core$println_appender$fn__5755@320defc8"]}}}

on v6 it outputs:

(require '[taoensso.timbre :as timbre])
=> nil
(= timbre/*config* (var-get (resolve 'taoensso.timbre/example-config)))
=> false
timbre/*config*
=>
{:min-level :debug,
 :ns-filter #{"*"},
 :middleware [],
 :timestamp-opts {:pattern :iso8601, :locale :jvm-default, :timezone :utc},
 :output-fn #object[taoensso.timbre$default_output_fn 0x53b7e015 "taoensso.timbre$default_output_fn@53b7e015"],
 :appenders {:println {:enabled? true,
                       :fn #object[taoensso.timbre.appenders.core$println_appender$fn__5835
                                   0x512839d8
                                   "taoensso.timbre.appenders.core$println_appender$fn__5835@512839d8"]}},
 :_init-config {:loaded-from-source :default, :compile-time-config {:min-level nil, :ns-pattern "*"}}}

This is because :_init-config is now present in timbre/*config* but not in (var-get (resolve 'taoensso.timbre/example-config)).

Because of this, it causes #32 to come back with v6 of timbre and the latest version of this library.

	(defn -init
	[]
	(let [default-config (var-get (resolve 'taoensso.timbre/example-config))]
	(when (and (compare-and-set! bootstrapped? false true) (= timbre/config default-config))
	(let [level (or (System/getProperty "TIMBRE_LEVEL") (System/getenv "TIMBRE_LEVEL") ":info")]
	(reset! slf4j-timbre.adapter/override-level (keyword (subs level 1))))
	(add-watch #'timbre/config ::on-first-config
	(fn [_ _ _ _]
	(reset! slf4j-timbre.adapter/override-level nil)
	(remove-watch #'timbre/config ::on-first-config)))))
	[[] (atom {})])