@kwladyka Because log4j2 is more modern so it has learned its lessons from all of the other libraries. slf4j treats FATAL and ERROR the same which annoys me. And just adding a single logging dependency is not enough when you have any complex app because you can guarantee you'll be bringing in multiple logging solutions from your dependencies so you're going to need all of the bridging dependencies too. And I like that we can configure log4j2 via properties files, instead of XML (it also supports YAML and JSON), and that we can control which config file it uses via environment variables and via JVM options.

Do you have link to simple example of project which use clojure.tools.logging with log4j2 where I can see appenders and configuration?

I don’t have energy to learn more this week and figure out this

https://github.com/seancorfield/next-jdbc/blob/master/test/log4j2-info.properties and https://github.com/seancorfield/next-jdbc/blob/master/deps.edn#L29-L36 is the only public stuff I have.

thank you

https://logging.apache.org/log4j/2.x/manual/configuration.html is the official doc page for configuration.

Why you don’t have :jvm-opts ["-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2"] in project?

(and, yeah, I spent days reading over the log4j2 stuff before deciding to make the switch at work -- there's a lot of info there)

;; 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"}

Any clever command to run or soemthing?

This project does not use clojure.tools.logging -- it's using log4j2 to control all the logging that the various JDBC drivers bring in.

Why not clojure.tools.logging?

The different JDBC drivers all use different logging libraries -- the bridges ensure that log4j2 ends up controlling all the logging.

next.jdbc doesn't do any logging itself, so it doesn't need c.t.l

I know, but when to use them? Should I add this dependencies always when start new project or under some conditions?

The answer to questions like that is always "it depends".

any hints how to decide?

This has all been discussed in the thread in #observability

hmm

See https://app.slack.com/client/T03RZGPFR/C010TGGL02X/thread/C010TGGL02X-1591958167.031100

I saw it, but I didn’t notice answer for my question

Which specific question doesn't it answer?

How to determine if and which dependencies should I add in the context of bridges to log4j2

As I said, the answer is "it depends".

but depends on what? 🙂

If you decide to use clojure.tools.logging yourself, then you get to choose which logging implementation you want to use with it, and you may need the logging.factory option to override the default choice it makes based on what else is on your classpath.

This is all about what is on your classpath in a specific project.

let’s say I will use :jvm-opts ["-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2"]

ok and how can I know what is there?

clojure -Stree or clojure -Spath

considering I use a lot of deps which use deps which use deps… any easy way to figure out when should I use bridge and which bridge?

It's up to you.

There is no "wrong" or "right" choice here.

hmm I think I don’t understand this part of Java logging 😉

Is it not like I want to bridge everything and remove or other loggers dependecies from project?

Using clojure.tools.logging directly in your project is a choice. Using a specific logging implementation for c.t.l is a choice. Bridging other logging implementations into that implementation is a choice. Only you can make those decisions.

Sorry if I have stupid questions, but why I could want to not bridge logging?

Some people like to control all logging in their app -- including logging from all the dependencies they use -- via one centralized system. Some people only want to control their own logging, and leave all the other logging alone.

oh ok I see

Did you read the Lambda Island blog post about logging?

yes, but it was very late and I was sleepy. I could not remember something.

While developing next.jdbc, I had left all the JDBC drivers' logging alone for a long time. I "didn't care" what each driver did -- because I felt that's up to users of next.jdbc to control.

but after all you decided to bridge everything to log4j2 right?

But when I was writing the new multiple result set support, I needed more control over debugging and logging so that I could a) control the level of logging separately for each JDBC driver and b) make PostgreSQL's logging more detailed since that was the driver I was having problems with.

Thank you. Your answers saved me at least 1 week of live :)

So, even tho' next.jdbc doesn't use clojure.tools.logging at all, I decided to bridge all logging to log4j2 since I prefer its configuration approach, and then I could dial logging up or down for individual libraries in one centralized place. This only mattered while I was debugging multiple result sets: so I could focus logging on a single JDBC driver at a time.

going 1 level deeper, if I plan to use tracer (https://cloud.google.com/trace) it is still good approach to use clojure.tools.logging with log4j2? I didn’t use tracers so far.

The TL;DR is that this only matters if you care about a specific library's logging -- which I didn't... until recently... and still only for testing rather than anyone's general usage of next.jdbc.

I have no idea about any of the GCP stuff.

but considering any tracer?

I have no idea. I don't use tracers.

ok, thank you

These are your decisions to make, not mine.

it was really helpful!

sure, just your hints save weeks of my live to figure out what decisions I can make 🙂

OK. Glad it was useful. As you can see from the thread in #observability different people have different preferences when it comes to logging libraries 🙂

yes, your sounds similar to main

I don't like slf4j -- primarily because it treats FATAL the same as ERROR and that's just wrong, in my opinion.

I care about 100% of logs

debugging without this can be nightmare

(we used to use slf4j at work "by default" and the FATAL/ERROR thing was the main reason I switched away from it)

and I can even not know about the issue because of this

hmm I think I didn’t experience FATAL (app abort) so far

the craziest issue which I had was websocket connection when call API and prase XML file. For some reasons it stack during parsing and froze whole APP forever. No exceptions, totally nothing. I took me so long time to figure out. I solved this by adding params to timeout for sockets when running app in jvm.

It (FATAL) is just a logging level -- but we wanted it separate from ERROR in testing because we deliberately do some things that we want to suppress logging of in some tests (that would otherwise log ERROR level stuff) but we still want to see FATAL level stuff -- and you can't do that with slf4j.

once again thank you for your hints today and for hints in the past ❤️

however heart looks strange here haha 😉

🍻