[deleted]
Why a Logging Framework Should Not Log
41–50 of 58 posts
Re: Why a Logging Framework Should Not Log
#42The logging in java is supper idiotic. This is because everyone agrees that Java's logging is shit. So every library uses something else. I have a small project and have 4 logging systems (that I had to integrate). ps: if you are a business person and have an option on this, I don't care for it regardless of your pov.
Yup. This is the best that I've found: (Gradle dependencies format) compile group: 'ch.qos.logback:logback-classic:1.1.3' compile group: 'org.slf4j:jcl-over-slf4j:1.7.12' compile group: 'org.slf4j:jul-to-slf4j:1.7.12' compile group: 'org.slf4j:log4j-over-slf4j:1.7.12' At least you only need to configure one logging subsystem then.
slf4j API should be in the compile group. At minimum, logback-classic should be runtime, as should jul-to-slf4j.
Re: Why a Logging Framework Should Not Log
#43Earlier quoted context omitted.
What reasonable default behaviour? If you're writing a console application, dumping to stderr is probably not a good idea - writing random log files that the end-user/admin has no idea about is probably not a good idea - shutting up and doing nothing is probably not a good idea (Java code has a tendency to use logging to warn about non-fatal configuration errors, etc). And let's not get started on what verbosity to s…
If you are creating a library? You shouldn't log at all. Return errors or throw them - do not log. If you are creating a console application? Stderr is the standard way to log errors. Let the user decide if where it points to. If you are creating a daemon, set the log destiny at the launch script. The application can either log to stderr anyway and let the script handle everything, or offer a parameter for setting th…
Logging is useful for more than just error conditions; how does that square with your advice to library authors?
Re: Why a Logging Framework Should Not Log
#44Earlier quoted context omitted.
If you are creating a library? You shouldn't log at all. Return errors or throw them - do not log. If you are creating a console application? Stderr is the standard way to log errors. Let the user decide if where it points to. If you are creating a daemon, set the log destiny at the launch script. The application can either log to stderr anyway and let the script handle everything, or offer a parameter for setting th…
Logging is useful for more than just error conditions; how does that square with your advice to library authors?
If it's not an error condition, you return it.
Libraries must not do any covert IO (in fact, any covert anything). A logging library is the only one that should log, and not their own messages.
They may write into some main application supplied collector, if it is not global, or if it is clearly handled as a message passing API.
The Java way is simply bad.
Re: Why a Logging Framework Should Not Log
#45Earlier quoted context omitted.
Yup. This is the best that I've found: (Gradle dependencies format) compile group: 'ch.qos.logback:logback-classic:1.1.3' compile group: 'org.slf4j:jcl-over-slf4j:1.7.12' compile group: 'org.slf4j:jul-to-slf4j:1.7.12' compile group: 'org.slf4j:log4j-over-slf4j:1.7.12' At least you only need to configure one logging subsystem then.
slf4j API should be in the compile group. At minimum, logback-classic should be runtime, as should jul-to-slf4j.
Good points. This config is from an app - not a library.
Re: Why a Logging Framework Should Not Log
#46The logging in java is supper idiotic. This is because everyone agrees that Java's logging is shit. So every library uses something else. I have a small project and have 4 logging systems (that I had to integrate). ps: if you are a business person and have an option on this, I don't care for it regardless of your pov.
Yeah, it's the exact situation described in that XKCD: "There are 14 competing standards! Let's create one that is perfect for everyone's use-case!" "There are 15 competing standards..." https://xkcd.com/927/ And, as you noticed, pretty much every Java project will reach a point where it has to deal with all four-ish of the major logging frameworks. Some module, somewhere, will include an Apache dependency and then y…
I like to imagine that particular XKCD was written with Java logging in mind.
Re: Why a Logging Framework Should Not Log
#47Earlier quoted context omitted.
My framework is built in Clojure. The interpreter is always there. Think of it like a statistics library with R. The idea of a "main application" is itself not a clear one. There are a set of functions you can use. Whether you choose to launch directly over the library or import it is a matter of convenience.
I would say that the responsibility to define a backend falls either on the Clojure interpreter or the user of the interpreter, then. Java is not typically run on an interpreter shell and the defaults that normally are sensible for Java probably aren't appropriate there. It's a perfectly sensible default for a framework to warn you at runtime that it's not configured properly, and stderr is the appropriate channel fo…
I don't think any of this is a Clojure specific issue. You can do all of the same things in Clojure with JVM logging libraries as you can in Java.
Re: Why a Logging Framework Should Not Log
#48Earlier quoted context omitted.
Logging is useful for more than just error conditions; how does that square with your advice to library authors?
If it's not an error condition, you return it. Libraries must not do any covert IO (in fact, any covert anything). A logging library is the only one that should log, and not their own messages. They may write into some main application supplied collector, if it is not global, or if it is clearly handled as a message passing API. The Java way is simply bad.
Maybe I'm misunderstanding your point -- by "do not log," do you mean do not call logging statements in a logging library's API, or simply do not force a concrete implementation of a logging library? I understand and agree with the second one completely, but the first one seems unrealistic.
I can't see how the Apache httpclient library could sanely "return" the different state transitions and pieces of data that are logged in its wire-level logging, but this is certainly a case where the logging statements are welcome.
Re: Why a Logging Framework Should Not Log
#49I really wish Java developers would just use java.util.logging and be done with it.
That's an all-or-nothing solution. As third-party libraries often use alternative loggers, and java.util.logging cannot be substituted on the classpath (because of the java.* namespace), then using JUL locks consumers out of using their own logging facade as it cannot be bridged to SLF4J.
java.util.logging can be bridged into SLF4J using the jul-to-slf4j bridge.
Re: Why a Logging Framework Should Not Log
#50The logging in java is supper idiotic. This is because everyone agrees that Java's logging is shit. So every library uses something else. I have a small project and have 4 logging systems (that I had to integrate). ps: if you are a business person and have an option on this, I don't care for it regardless of your pov.
Yeah, it's the exact situation described in that XKCD: "There are 14 competing standards! Let's create one that is perfect for everyone's use-case!" "There are 15 competing standards..." https://xkcd.com/927/ And, as you noticed, pretty much every Java project will reach a point where it has to deal with all four-ish of the major logging frameworks. Some module, somewhere, will include an Apache dependency and then y…
I doubt that you have used the SLF4J bridge in any realsitic situation, else you would not say that it works.