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