[slf4j-user] Library best practice

[Ceki Gülcü]

Hello Martin,

How are you configuring the LogProvider in the Config class?  If I
understand correctly, Jericho HTML Parser will be used as a
library. Now, with the LogProvider approach you are saving a dependency,
e.g. SLF4J, but you might be imposing an extra configuration step.
Assuming some other library uses SLF4J, the end-user will be have
configure SLF4J *and* Jericho's LogProvider. If there are N libraries
each with its own LogProvider mechanism, the user will need at least
N+1 configuration steps.

Does the above make sense?

At 03:24 PM 3/14/2007, Martin Jericho wrote:
>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

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch