pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: Logging
Date Wed, 05 Dec 2012 22:03:05 GMT

> slf4j-api has no dependencies, so adding it to Pivot's internal codebase would only add
one dependency to Pivot.  ...
yes, but even to add it as a dependency we have to look if it's a
wanted dependency ... or maybe find a way to load it dynamically in a
way like for service providers.

> 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).
yes, I agree completely with you, and probably JUL is used very little
(at least in enterprise apps, my main field). But if all differences
hare could be handled with a different configuration file (and I'm not
sure, but we can verify/test in the meantime), could be good the same.

So my proposal here is:
- write in core Pivot general logging interfaces
    -- note that after this the problem could be: what could be useful
to log inside Pivot (other than exceptions) ?
        --- From my point of view, all important events, and for
example any event that starts/stop a connection requesting data (and
maybe even dumping request parameters and the returned response), but
there are many others ... suggestions here ?
        --- this could be an enhancements to add later ...

- provide a (default ?) implementation using System.out/err
- maybe provide an implementation using JUL
- write another implementation using directly slf4j and put it under
apache-extras (in a new subproject, or in one of existing ones) ...

What do you think on this ? (all included, even other Pivot Developers :-) )

> I definitely think Pivot should stay away from commons-logging, for reasons explained
> http://articles.qos.ch/classloader.html
yes, I agree even here :-) ... commons-logging could cause strange
problems with classloaders, usually I prefer a direct usage of slf4j
or log4j ... thanks for the info.

> 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)
This is not so simple at Apache, we have strict rules on the usage of
other libraries/products:
they must have a license compatible with the Apache license, we must
provide all reference in a certain way, distribute them under many
constraints, etc. . So even tasks like repackaging libraries is best
done in outside code/scripts ...

So generally speaking I'd prefer to not depend on other
libraries/products that is not critical to Pivot or is not an Apache
product, even if small (few KB).

For example, to handle Charts we have some interfaces in the Pivot
Charts project (delivered in core Pivot), and a real implementation
(using a JFreeChart provider) in one of our subprojects at
Apache-Extras, here:
so maybe in this case we could try a similar approach ... of course if
it worth the effort (the resulting code is not too much
complex/oversized). But for me logging is a really important feature,
so the effort could be right.

Anyway, thanks for all the info and discussion on this feature.
Be free to post other info/comments here and/or in the issue,
discussing thing is a way for us to understand better if/how to
implement them. If you have some minimal prototype/code block, the
best is to zip it and attach in the related jira issue (generally


View raw message