On 04/01/2012 04:26 PM, Christian Grün wrote:
Hi Charles,
Is the decision to use an in-house logging framework open to reconsideration? I'd be willing to do a first-draft cut on a transition to log4j, Sun's java.util.logging, or Apache Commons Logging (a thin indirection layer which can use either of those as an underlying backend) if there's agreement to do so.
Thanks for your offer. While our current log architecture seems to have covered most requirements (regarding the feedback we've got on it), I have no doubt it can be further improved, so your draft is welcome. Intuitively, I'd first stick with Java's default logging mechanism, as the BaseX core is supposed to work without any additional libraries (but of course we could switch over to other logging libraries if they are found in the classpath).
Howdy, Christian --
Could you quickly run through the requirements for a logging system in BaseX, to be sure we're on the same page?
The things I personally want which I don't understand to be presently available:
[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).