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 _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
