Finally had a chance to setup log4j2 based on recommendations from this channel. It works great! My question is around what needs to be excluded (if anything). For example, I followed https://gist.github.com/ataggart/ac208c289c5d01dacf3b4b341a1c37f0 + Sean’s suggestions. Now, TMK the exclusions from the gist, because i’m using deps.edn , don’t happen globally but at the individual dep level. So, how can I figure out which dep I need to add the excludes to? Do I even need to exclude anything?

@tkjone I've never needed to exclude anything.

if you do want to check if something is being loaded that shouldn't then clj -Stree is your friend

So, just to confirm I understand, we would just run clj -Stree and if any of the deps specified in https://lambdaisland.com/blog/2020-06-12-logging-in-clojure-making-sense-of-the-mess (as an example) appear as a dep of one of my logging library, those might be good candidates to exclude? As an example, I can run clj -Stree right now and I get something like

; ...
org.apache.logging.log4j/log4j-jcl 2.13.0
  commons-logging/commons-logging 1.2
; ...

If you have all the log4j2 bridges as top-level dependencies, I don't think it matters if anything else brings them in as transitive dependencies?

I don't exclude other logging implementations and I haven't seen any problems (and we depend on a ton of stuff that drags in other logging implementations, I'm sure... but let me check).

Hmm, apparently less than I thought.

org.clojure/tools.logging 1.1.0
  commons-logging/commons-logging 1.1.1

(we do not exclude commons logging from tools.logging)

https://gist.github.com/ataggart/ac208c289c5d01dacf3b4b341a1c37f0

@ataggart That was what @tkjone linked to about half an hour ago that started this discussion 🙂

ha ok, I just have a slack alert on "logging"

I've never needed to exclude other logging dependencies -- do you know when that is needed?

(given that deps.edn doesn't have global exclusions)

transitive dependencies

some libraries declare dependencies on implementations

unfortunately

I can see it might matter with Leiningen/Boot because of Aether.

So... maybe I'm just lucky I've never been bitten by it...?

yeah, I included it in the example to remove one possible source of problems

heh, so maybe the take away is that based on my current set of dependencies I am using + the fact that lein + tools.deps have a different process for resolving deps, I am good to avoid exclusions for now (because they are not appearing as transitive deps from what I can see).

However, should I add new deps, it would be good to check if any exclusions need to be made

Here's all we have at work

;; use log4j 2.x:
    org.apache.logging.log4j/log4j-api {:mvn/version "2.13.3"}
    ;; bridge into log4j:
    org.apache.logging.log4j/log4j-1.2-api {:mvn/version "2.13.3"}
    org.apache.logging.log4j/log4j-jcl {:mvn/version "2.13.3"}
    org.apache.logging.log4j/log4j-jul {:mvn/version "2.13.3"}
    org.apache.logging.log4j/log4j-slf4j-impl {:mvn/version "2.13.3"}

(and no exclusions)

Looks like the bridges bring in core anyway:

org.apache.logging.log4j/log4j-slf4j-impl 2.13.3
    org.apache.logging.log4j/log4j-core 2.13.3

log4j-core is a dependency of log4j-slf4j-impl

damm slow typer

ok, going back to work

Thanks all!