Fork me on GitHub
#observability
<
2020-07-08
>
athomasoriginal16:07:47

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?

seancorfield16:07:53

@tkjone I've never needed to exclude anything.

👍 3
plexus16:07:50

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

athomasoriginal16:07:29

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
; ...
Perhaps I would exclude commons-logging/commons-logging from org.apache.logging.log4j/log4j-jcl.

seancorfield16:07:08

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?

seancorfield16:07:02

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).

seancorfield17:07:29

Hmm, apparently less than I thought.

org.clojure/tools.logging 1.1.0
  commons-logging/commons-logging 1.1.1
The rest is all org.apache.logging.log4j stuff (which is log4j2)

seancorfield17:07:57

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

seancorfield17:07:47

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

ataggart17:07:02

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

seancorfield17:07:19

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

seancorfield17:07:33

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

ataggart17:07:40

transitive dependencies

ataggart17:07:06

some libraries declare dependencies on implementations

ataggart17:07:16

unfortunately

seancorfield17:07:22

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

seancorfield17:07:57

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

ataggart17:07:55

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

athomasoriginal17:07:23

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).

athomasoriginal17:07:42

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

seancorfield17:07:25

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"}
We don't even have log4j-core

seancorfield17:07:33

(and no exclusions)

seancorfield17:07:42

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
from -Stree

ataggart17:07:00

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

ataggart17:07:06

damm slow typer

ataggart17:07:30

ok, going back to work