On 04/01/2012 05:24 PM, Christian Grün wrote:
Could you quickly run through the requirements for a logging system in
BaseX, to be sure we're on the same page?
Just a short one... It might be a good start to check out the existing
debug mode, which is very cheap, too, and rewrite it in a way such
that this output is redirected to the logging library. For more
details, it might be worth talking to Dimitar, as he had some similar
thoughts just a few time ago (for now, I'd still prefer to stick with
the standard Java libraries -- even if the external library has just a
few kb -- and dynamically plug in a more advanced solution,
automatically or via reflection).
Work started on that, present in my github tree
(https://github.com/charles-dyfis-net/basex/commits/java_util_logging).
This is the first time I've used java.util.logging, and I have a few
gripes about it (most particularly, the need to construct new Object[]
arrays to store format string parameters means that calls that aren't
logged are not nearly as cheap as they might otherwise be, leading to
the need for a lot of logger.isLoggable() calls wrapping blocks with log
messages if we want to code for optimal performance... *sigh*).
That said, I'll get this to a point where it has functional parity with
old behavior (respecting DEBUG, the -z flag, etc) and let folks know
when it's ready for testing or early review. Note that I'm by no means a
"Java developer", so I expect no small amount of feedback on anything
this large. :)
FYI -- I rather strongly disagree with building our own indirection
layer to dynamically switch between logging libraries, when at least two
such layers already exist on the market (and one of them is already
found in our dependency chain); writing an indirection layer that
switches between indirection layers is considered an antipattern for
reasons I consider to be pretty good ones, which the slf4j folks
document in their FAQ[1]... but we can have that discussion later;
supporting java.util.logging is a reasonable first step before we
consider others.
[1] http://www.slf4j.org/faq.html#optional_dependency
Christian
______________________________
[High priority]
- Ability to add cheap trace-level logging at any point in the code (not
only places which have been passed a handle to the single logger instance);
"cheap" in this case meaning having no significant performance impact when
active log level is below this point.
- Ability to toggle detailed logging for very specific components (ie. only
for org.basex.query.func.JavaModuleFunc) via configuration changes only.
[Medium priority]
- Ability to enable stack traces for log messages which may not include them
by default as a configuration-only (no-code-change) capability.
[Low priority]
- Ability to use appenders for remote logging, auto-rotated logging, or
similar advanced functionality, where using such appenders is necessary to
be compliant with local standards (I'm in a Java shop, so we have a typical
set of log4j appenders used).
The principal reason I'd consider Apache Commons Logging is that it
automates the process of switching to alternate logging libraries, rather
than needing to write the indirection layer ourselves; a 3rd party embedding
a library will typically prefer that it support their choice of native
logging libraries -- and as log4j is far more widely used than
java.util.logging (which is both newer and less capable), supporting it is
often expected. That said -- it *does* add a 3rd-party 60K jar to the
necessary set of libraries (more if one wants to use it to target something
other than log4j or java.util.logging).
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
