The ability to allow consumers to bind at runtime the implementation they want by providing an api jar is kind of a neat idea.
The thing I dislike the most is when libraries force me to use their logging runtime. If they need it just for tests they should add the 'test' scope and just use the 'api' jar as a 'compile' dependency.
http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
Though the author does have a point that fault here could be put on the library that added the dependency without a default logging behavior. However I'd still blame SLF4J for making the default case suboptimal.
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.
That way the console can tell you about configuration errors, and by default the library will log nothing. If the library author considers it important to log somewhere, the library author is responsible for putting both an understandable warning up, and writing documentation.
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.
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.
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.
But a library, that your code will call, must not log. Ever. That includes any portion of a framework that you have to call, but it using services upper on the stack can make this rule hard to see. It must not include a logger implementation, and not call any global logger supplied from you.
It seems we are arguing over the definition of those two cases.
If so, I would have to disagree based on pragmatic grounds, unless you have another credible way to acquire the information present in http wire logging or connection pool events, for example.