Solve logging

We used to have some INFO logs, but they were considered spam by some users (#1439), so they were reduced to FINE (#1449). In general, open source libraries don’t log unless something is going wrong, and these log statements didn’t imply something was wrong.

However, in #1538 INFO-level logs were added back (in a different place, but same effective event). These could be a lower level, but it seems difficult for users to enable a higher logging level.

We do know applications can do something like this to squelch what is logged:

// May need to save this reference
Logger log = Logger.getlogger("io.grpc");
log.setLevel(Level.WARNING);

More than one project has been annoyed with the logging-by-default, but the number of Java developers who can handle logging.properties seems limited.

On Android, things are even worse because most phones almost always return false from Log.isLoggable() for lower log levels. Developer phones (like debug builds of Android) will return true, but few develop on such phones. This means that even when you configure java.util.logging to log lower levels, they won’t actually be logged. You can run a command like adb shell setprop log.tag.<MAGICTAG> VERBOSE for each class you want to log, where the MAGICTAG can be found from DalvikLogging.loggerNameToTag(), but this is so painful it isn’t close to practical.

Note that most Android applications don’t notice any problem with Log.isLoggable() because while it may return false, if you call the log anyway (say, via Log.v()) apparently it will be logged.

One developer suggested we use slf4j because it is “java best practices.” I think in some part of the Java world it is, but it is unclear whether grpc exists in that part of the world. The number of developers that can configure java.util.logging, log4j, logback, or slf4j is certainly higher than just java.util.logging, but it will also become harder to direct users in how to enable logging when we need it for a report. It also has the deficiency that “If no binding is found on the class path, then SLF4J will default to a no-operation implementation” which is pretty bad for our WARNING statements.

[dieselpoint]

SLF4J gets a BIG THUMBS DOWN!

I can’t disagree more strongly. Slf4j isn’t a logging framework, it’s a facade. It’s just a set of interfaces. The underlying implementation can be anything. JUL doesn’t easily allow other implementations.

GRPC is a library that fits into other apps, and it really should use whatever logging implementation the underlying app uses. The means that GRPC must write to an interface. You can either roll your own interface, or use Slf4j. I think Slf4j is a better choice.

[craigday]

SLF4J gets a BIG THUMBS DOWN! from me. GRPC is (wonderful) infrastructure code/functionality. It should stick with JUL. It’s extremely annoying when library vendors choose a logging framework that you then have to cater for. I don’t have to think about JUL. It’s just there and it just works, and I can push it through any logging setup I choose!!