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