pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Swor <sworisbreath...@gmail.com>
Subject Re: Logging
Date Tue, 04 Dec 2012 01:43:47 GMT
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

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)


On Tue, Dec 4, 2012 at 11:35 AM, Sandro Martini <sandro.martini@gmail.com>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

View raw message