Users have reported seeing `Wrong number of args (9) passed to: timbre/-log!`
errors via slf4j-timbre when upgrading from Timbre v4.4.0 -> v4.5.0.
slf4j-timbre already uses the correct public API (timbre/log!), so this looks
like an AOT issue: a compiled Timbre v4.4.0 `log!` macro expansion is calling
a `v4.5.0` `-log!` function and breaking.
Unfortunately, looks[1] like a user-level call to `lein clean` isn't enough to
resolve the issue. Might be that slf4j-timbre itself needs to be recompiled?
Whatever the underlying cause, this should be a reasonable workaround for now.
[1] : https://github.com/fzakaria/slf4j-timbre/issues/20#issuecomment-229254285
Choosing not to squash into previous commit since we're introducing
a bunch of JVM-specific code here. If we do later decide to do a
.cljx port, will be handy to have the previous code around as a
platform agnostic option.
Appender arg changes:
- REMOVED: :data-output-fn, :hash-arg_
- Deprecated: :?err_, :vargs_ (no point in delaying these now)
- New: :?err, :vargs, :?msg-fmt, :hash_, :output_, :?meta
Implementation notes:
- Have unified all vargs processing during margs phase
- vargs no longer contains message format; now extracted as separate :?msg-fmt
- :output-fn and :timezone_ are now cached between appenders when possible
- :output_ now provides a convenient, cache-aware way of getting formatted ouput
- Hash stuff is now non-configurable but far more predictable; if appenders
have specific needs beyond :hash_, they should use a custom (fn [data]).
This is a bit of a pita (and still doesn't solve issues when user
adds logging calls w/in her own macros); but it's better than nothing
while we wait on some kind of resolution to CLJ-865.
This lets folks more easily use Chrome blackboxing but it'd still be
nice to get a proper general-case line number solution.
Seems like our options are:
1. Waiting on CLJ-865 (which'd still leave us w/o accurate source
map links?).
2. Something like https://gist.github.com/bgrins/5108712 (doesn't
seem possible if we want a more elaborate wrapper?)
3. Other ideas??
This is useful since it allows one to dynamically set the log level
prior to ClojureScript compilation. Specifically, I would like to
use this inside of a Boot task.
Hashing is still done on a data level as before (with arb data-hash-fn);
difference is that {:timbre/hash _} arg0 support is now baked in to core
logging impl. rather than just the default data hash fn.
Effect: a new `:?hash-arg` is now provided as part of core data and will
be available to any data-hash-fns.
New implementation is also cleaner + faster.
- This simplifies the requirements for appender authors.
- Note that middleware authors still need to be careful since
it'd be infeasible to offer similar protection between each
individual layer of middleware.