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