[slf4j-user] Library best practice

[Martin Jericho]

Thanks everyone for your help so far.  I have been experimenting a bit in 
the meantime and would like to bounce a couple of ideas around.

Ceki wrote:
>What is your motivation for wishing to have a single logger
> for the whole library?

I understand from Boris' response that the current best practice for a 
library is to have the following line in each class:
Logger logger=LoggerFactory.getLogger(MyClass.class);

My library (Jericho HTML Parser) creates a lot of objects, and although the 
only real work performed by the call to LoggerFactory.getLogger(...) is a 
HashMap lookup, I still don't like the idea of adding in this overhead just 
to give some user the luxury of filtering a few log messages in what I would 
consider to be very rare circumstances.  I have decided that my 
implementation will have a single logger associated with the Source 
document, and use the package name.  I'm not advocating that for all 
libraries, I just think mine has special considerations, and is simple 
enough that there would be little use for more fine-grained logging.

The more interesting aspect of what I have done is to allow the library to 
hook into SLF4J logging, or any other logging system, but still keep it 
completely free of runtime dependencies.  I did this by defining my own Log 
interface and LogProvider abstract class, and including an SLF4J 
implementation, requiring the slf4j-api to compile, but only requiring SLF4J 
jars at runtime if it has actually been selected.  Implementations that just 
write to STDERR or a user-specified Writer are also provided, requiring no 
other jars at runtime, and although any other logging system can be plugged 
in through SLF4J, I will probably add a couple of the common ones as native 
implementations.
If anyone's interested, a development version of my library that uses this 
approach is here:
http://jerichohtml.sourceforge.net/temp/jericho-html-2.4-dev-logging.zip

This might sound like I'm re-inventing the SLF4J wheel as a part of my own 
library, which is the case to some extent, but the amount of code required 
is quite minimal, and the only additions to the public API are the Log 
interface and LogProvider abstract class.  The huge benefit is that my 
library is still dependency free, which I think is an aspect that would 
appeal to many other library developers.

Has anyone tried compiling the slf4j-api source files into their library 
rather than requiring it as a dependency?  The LoggerFactory class would 
need to be slightly modified so that it would use an SLF4J implementation if 
a StaticLoggerBinder class is detected, but also provide a programmatic or 
configuration based means of specifying an implementation so that the 
library can be used without any SLF4J jars at runtime.  Wouldn't that appeal 
to more library developers than the current approach?  Would there be any 
licensing issues with using the current SLF4J source code in this way?

Regards
Martin 

Send instant messages to your online friends http://au.messenger.yahoo.com