Logging with SLF4J?

[GoogleCodeExporter]

Considering the fact that bitcoinj may be used in several environments i 
suggest to replace the 'homebrewn' logging facility with slf4j [1].

IMHO this is the best solution to handle logging in libraries as it does not 
force the user to use a specific logging library.

I have attached a patch that replaces all LOG instances with slf4j. You'll need 
the file slf4j-api.jar while compiling and an implementation while running.

[1] http://www.slf4j.org/faq.html#what_is

Original issue reported on code.google.com by fha...@gmail.com on 21 Apr 2011 at 7:38

Attachments:

• bitcoinj-slf4j.patch

[GoogleCodeExporter]

I'll investigate SLF4J after finishing off the current pieces of work.

The reason I didn't use a framework for logging in this library is because most 
Java logging frameworks seem to be way over-engineered, and in the past I've 
sometimes had trouble configuring them properly. If you have to spend more than 
10 seconds thinking about logging it's too much. The SLF4J FAQ says that it is 
not, by itself, enough to actually log things and you probably have to learn 
about some other logging framework to actually get useful output.

If somebody wants to have the bitcoinj logging tied through to log4j or some 
other such system, they could just edit the Utils class to do so. Everyone else 
doesn't have to worry.

Original comment by hearn@google.com on 25 Apr 2011 at 11:43

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

SLF4J is just your 'just edit the Utils class' approach after it has evolved 
for some time. Bitcoinj users could use log4j, j.u.l and other logging 
frameworks without changing the code just by swapping out the runtime 
implementation.

To make my patch work just throw in slf4j-simple.jar into the classpath.

Original comment by fha...@gmail.com on 25 Apr 2011 at 6:23

[GoogleCodeExporter]

Getting myself into a discussion about Java logging may not be such a good idea 
(might as well try to advise people to use vi over emacs), but here is my two 
RMB:

What strikes me as odd about the myriad logging frameworks is that while they 
all claim to be mostly concerned about enabling the user to configure the 
logging backend and output style to their personal preferences in a unified way 
(and that is a very important goal), they also seem to take the opposite 
approach regarding the freedom of choice for library developers by forcing them 
to use their specific logging API, always introducing an extra dependency.

As a library developer, I would much rather start using the logging API that 
already comes with the JDK (java.util.logging) until its unfriendliness gets 
too much for me that I can justify the extra dependency on another logging API.

java.util.logging is a rather limited and clumsy API for the library developer, 
and the only reason I would ever choose it is just to avoid the extra 
dependency (which for small projects is a good reason), but I cannot see why 
our choice of API should have any impact on how the user wants to configure the 
logging backend. Configuring j.u.l with just the JDK-provided mechanisms is 
also a nightmare, but this is what I was expecting the plentiful logging 
frameworks to focus on (rather than introducing their own API).  

Is it possible to use java.util.logging and still have the user configure what 
gets logged and how using SLF4J? If not, why not?  

Original comment by thilopl...@googlemail.com on 29 Apr 2011 at 2:32

[GoogleCodeExporter]

> What strikes me as odd about the myriad logging frameworks
SLF4J is no logging framework. It's merely a Simple Logging Facade that 'wraps' 
several common logging frameworks.

> As a library developer
Actually that thought was what made me search for alternatives to log4j. Now I 
believe that forcing the library user to use a specific library is bad. 
Especially if that library isn't the one that he uses for the project. SLF4J 
enables the library user to integrate library logging with his logging 
framework of choice. And in the case he just don't care SLF4J will fallback to 
a nop backend.

> Is it possible to use java.util.logging and still have the user configure 
what gets logged and how using SLF4J? If not, why not?

Depends on how i understand the question:

- use jul as a backend and configure what get's logged in java.util.logging:
yes ... that's possible. You configure what get's output just like if you'd use 
jul directly. When using jul configuring happens in the logging.properties file 
just like before.

- use jul as a backend and configure what get's logged in SLF4J:
no ... that's not possible. The logging API doesn't care about enabled or 
disabled loggers. When logging you just define which level a certain output 
will be.

I want to stress that the same is true for the other logging backends. Users 
that prefer log4j will be able to use log4j for their logging purposes. On 
android native android logging can be used (which is one of the reasons i'd 
vote for slf4j).

Original comment by fha...@gmail.com on 29 Apr 2011 at 8:27

[GoogleCodeExporter]

I'll merge in this change along with a few others next week. It's not a big 
deal either way. If the SLF4J "simple" logger turns out to be too simple or too 
complicated I'll just whip one up that works the good old fashioned way: on/off 
with a command line flag.

Original comment by hearn@google.com on 29 Apr 2011 at 9:16

[GoogleCodeExporter]

This issue was closed by revision r67.

Original comment by hearn@google.com on 2 May 2011 at 12:35

• Changed state: Fixed