[slf4j-user] Library best practice

[Martin Jericho]

Hi Simon and Ceki,

Thanks again for the feedback regarding my last post.

>> 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.

Simon wrote:
> Why would you bother? Why not just take SLF4J exactly as is, and rename 
> into your own namespace? If SLF4J uses an Apache license (and I think it 
> does) then this is perfectly legal. There is no point in writing a wrapper 
> for a wrapper...
>
> However if your code requires java1.4 or above, then why not just use 
> java.util.logging as your API? You can then plug in any implementation of 
> that API you want while the code depends on just the jdk.

Using the java 1.4 API is a good idea.  I had never really looked into it 
very much when I first saw that you have to use a concrete Logger class 
instead of an interface, but now that I've investigated it further I 
actually quite like it.  The only thing that makes this untidy is Sun's bad 
implementation of Logger, which hard codes the level check using internal 
variables in each log convenience method, instead of calling the 
isLoggable(Level) method.  I had to subclass it to reimplement all of the 
convenience methods, which was made harder by the fact that nearly 
everything is private in their implementation as well.

The fact that SLF4J uses separate methods instead of having the equivalent 
of a Level class makes the isLoggable(Level) implementation a little 
inefficient, but probably negligibly so.

Although I will probably not go down the path of including SLF4J source code 
in my library, I would be interested to know whether it is in fact 
acceptable to include Apache licensed source in an LGPL licensed library. 
I'm not sure whether it would be that simple.

Ceki wrote:
>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?

Yes that is a good point as well.  My implementation now checks for the 
presence of the org.slf4j.impl.StaticLoggerBinder class, and defaults to 
using SLF4J through a java.util.logging.Logger wrapper if the class exists. 
Otherwise is uses standard Java logging.  I could extend this to check for 
other logging frameworks as well, but the current functionality at least 
allows the user to obtain a bridge to any other framework through SLF4J. 
The user can also explicitly set which framework to use via the static 
Config.LoggerProvider property, which would alleviate the problems that I 
believe are associated with JCL auto detection.

I would be interested to get some more feedback about this new design.  The 
complete library using this design is available here:
http://jerichohtml.sourceforge.net/temp/jericho-html-2.4-dev.java-logging.zip

Cheers
Martin 

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