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
