Why a Logging Framework Should Not Log • Hacker News Board

Re: Why a Logging Framework Should Not Log

#31

Post by phillord2 » Thu, May 05, 2016, 7:37 PM UTC

paulmd wrote: post #16

phillord wrote: post #10

Earlier 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…

Java is getting an interpreter shell, as it happens.

Logging should default to warn/error on standard err? I find this a strange idea. Having a "--verbose" switch is pretty standard on the command line. Some applications do have an "be absolutely silent" switch, true but that normally switches everything off.

Re: Why a Logging Framework Should Not Log

#32

Post by phillord2 » Thu, May 05, 2016, 7:49 PM UTC

xg15 wrote: post #29

I always found SLF4J's reasoning quite simple and logical and not at all an example of "those situations which show that software is difficult, and that often there are only compromises". I think the core problem in this case is that the author is not clear if they are writing a library or a (command line) application. The following workflow has always worked well for me: 1) Do you expect users of your project to use…

It's a set of clojure code that I expect people to use in an interactive shell by, yes, calling methods. Whether people do that within an IDE, directly at a REPL or by running a script is up to them.

I'm still not understanding why I should perform major surgery on my tool for the sake of a logging library which is a transitive dependency.

Nor am I understanding why I should pass the error message that confused me on to downstream users. I'm happy to make the decision rather than sit on the fence.

Re: Why a Logging Framework Should Not Log

#33

Post by phillord2 » Thu, May 05, 2016, 7:52 PM UTC

devonkim wrote: post #15

phillord wrote: post #11

Earlier quoted context omitted.

It's ugly advice. Wish there was a better alternative. Ideas on a post-card please.

The JVM works this way after C programs popularized the precedent - refuse to run at all with a dynamic link error stating the shared library that was expected without any mention of what version of the library should be present in the LD_LIBRARY_PATH or that the shared library version expected actually doesn't match the ABI in some corner cases and silently fails during runtime. That's part of why customizable class…

That is not what is happening with SLF4J. The nop logger is present in the API artifact. The API artifact chooses to warn when using it. The nop dependency, despite the name, contains no logger at all. It just explicitly forces the usage of the nop logger.

It's pretty clever actually, and works in a straight-forward way.

Re: Why a Logging Framework Should Not Log

#34

Post by m4dc4pXXX » Thu, May 05, 2016, 8:21 PM UTC

geophile wrote: post #26

puppetmaster3 wrote: post #9

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

Yes, this is exactly right. What a fucking nightmare. Every time I need to set up java logging for a new project, update a project, revisit an old project, I am dragged back to logging configuration hell. Which logging package do I use? What is the logging config file called and where do I put it? How do I specify it? What do I do if different packages use different packages? A logging layer on TOP of other logging p…

It's even more fun when your project uses native libraries, with their own logging, that you can't seem to override at all. (Looking at Mesos, right now.)

Re: Why a Logging Framework Should Not Log

#35

Post by bhaak » Thu, May 05, 2016, 8:38 PM UTC

puppetmaster3 wrote: post #9

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

So how does state-of-the-art logging work these days?

Re: Why a Logging Framework Should Not Log

#36

Post by marcosdumay » Thu, May 05, 2016, 9:25 PM UTC

vertex-four wrote: post #25

btilly wrote: post #17

Earlier quoted context omitted.

Right, it is configurable. But there is no reason why a configurable library can't have reasonable default behavior if no configuration is supplied. While still being configurable. If you're winding up as a buried dependency that end developers may not be aware of or care about, you want to do this.

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 the log channel.

The Java community fixation on logging is really not deserved. It's more caused by bad error handling by their main web servers than by any fundamental problem.

Re: Why a Logging Framework Should Not Log

#37

Post by yeukhon » Thu, May 05, 2016, 9:59 PM UTC

puppetmaster3 wrote: post #9

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

I do not think Java is the only outlier here. In general library authors should never force a logger to write to anything. It should be a do-nothing logger. It should provide a configuration so logs are going through the application utilizing the library. If I am wrong interpreting your comment, let me know.

[1]: http://docs.python-guide.org/en/latest/writing/logging/#logg...

Re: Why a Logging Framework Should Not Log

#38

Post by yeukhon » Thu, May 05, 2016, 10:01 PM UTC

bhaak wrote: post #35

puppetmaster3 wrote: post #9

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

So how does state-of-the-art logging work these days?

Well if you really want to talk to "state-of-the-art" the closest would be the principle of "12-factor application." So basically everything goes through stdout and stderr, and the dameon running the server (like monit or supervisord) just captures them and redirect to a stdout file and a stderr file.

Not hard, just so many people including myself is used to writing logger....

Re: Why a Logging Framework Should Not Log

#39

Post by xg15 » Thu, May 05, 2016, 10:19 PM UTC

phillord2 wrote: post #32

xg15 wrote: post #29

I always found SLF4J's reasoning quite simple and logical and not at all an example of "those situations which show that software is difficult, and that often there are only compromises". I think the core problem in this case is that the author is not clear if they are writing a library or a (command line) application. The following workflow has always worked well for me: 1) Do you expect users of your project to use…

It's a set of clojure code that I expect people to use in an interactive shell by, yes, calling methods. Whether people do that within an IDE, directly at a REPL or by running a script is up to them. I'm still not understanding why I should perform major surgery on my tool for the sake of a logging library which is a transitive dependency. Nor am I understanding why I should pass the error message that confused me on…

My point is that "not passing on the error message" could make life harder for downstream users too, depending on who those users are. (Sorry if my reply was arrogant or harsh - I got burned by this in the past, that's why I'm telling it)

If you're developing a project and use SLF4J by yourself, and use a third-party-dependency that already includes a logger implementation, this dependency can override your logging and cause all sorts of havoc. This can be a frustrating and hard to find bug.

(I'd say the fact that this can happen at all is a design flaw in it's own, partly caused by Maven's way of dependency resolution, partly by SLF4J. But I don't see that changing in the near future...)

I think it's important to consider how your project will be used. if it's really just for exploratory use in a REPL/a few scripts, then including a logger is fine. If you think this project could be used in larger projects, you should consider leaving it as it is or restructuring.

If you do include a logger, leave a note about it in the documentation. This way, users can at least exclude it again if they have to.

Re: Why a Logging Framework Should Not Log

#40

Post by uriahc » Thu, May 05, 2016, 10:32 PM UTC

puppetmaster3 wrote: post #9

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