My thoughts: slf4j-api has no dependencies, so adding it to Pivot's internal codebase would only add one dependency to Pivot. It defaults to a no-op implementation, so applications shouldn't break if there isn't an implementation library (logback-classic, slf4j-log4j12, et cetera) on the classpath.
My big concern with using JUL internally is that developers who choose to use a different logging system for enterprise apps (logback or log4j) would either have to maintain separate logging configuration files (one for JUL and one for their other logging implementation) or bridge it with something like jul-to-slf4j (which incurs a performance penalty). I definitely think Pivot should stay away from commons-logging, for reasons explained here: http://articles.qos.ch/classloader.html If a third-party logging API is added as a dependency to Pivot, documentation could be added to include a download link to the required library jar for non-Maven projects. Alternatively, it might be possible to embed the API library via JarJar (ASM actually encourages its users to do this... see the note at the bottom of http://asm.ow2.org/doc/faq.html) -Steve On Tue, Dec 4, 2012 at 11:35 AM, Sandro Martini <[email protected]>wrote: > Hi Paul, > > > SLF4J is widely used. Emphasis on loose coupling. It's an abstraction > layer or facade (the "F" in SLF4J) that allows for switching out the > implementation behind the interface (log4j, logback, JUL, etc.). > yes, I agree with you, probably SLF4J ( http://www.slf4j.org/ ) is a > more general option than Log4J and Commons-Logging. > > An last, on licensing (get from SLF4J site): > > SLF4J source code and binaries are distributed under the MIT license. > so there shouldn't be problems. > > > So really I think we could chose the same approach used for Pivot Charts: > we should think on a right way to abstract this, and deliver a default > implementation bundled in Pivot targeting only Java logging classes > (to avoid additional dependencies), and other implementations (like > that for slf4j) in one of our apache-extras subproject ... coulf be > great. > > Or someone prefers a bundled version with direct support for SL4FJ ? > (generally speaking I'd prefer to avoid, to not have other dependencies) > > > As a side note: in some my test Javascript Pivot application > (committed under tests) I wrote some simple method to call > System.out/System.err from js code ... probably with our Logging > facilities even those sampels should be update to use it, at least to > have a sample and ensure that all is callable right even from js. > > > Just updated the jira issue with a reference to this discussion (on > Nabble) ... > > > Bye >
