Am Montag, 2. April 2012, 09:52:46 schrieb Charles Duffy:
On 04/02/2012 08:07 AM, Christian Grün wrote:
Work started on that, present in my github tree (https://github.com/charles-dyfis-net/basex/commits/java_util_logging).
Good news, I'll look at that soon.
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 [...]
True. All this is related to a more general question: do we want to allow dependencies to other libraries in the BaseX core, or do we want the core to stay monolithic/as is? As we are accumulating more and more projects that are embedded only if they are available in the classpath (igo, tagsoup, jline, xml-resolver, ...), our current approach may get too limiting at some stage. On the other hand, people frequently appreciate the fact that the BaseX core still works out-of-the-box without any dependencies.
If we decide to abandon our ascetic attitude, we may still have to decide which libraries won't introduce too much redundancy in terms of functionality; on the other hand, it will be much easier to embed other projects into our core product. And, last but not least, we could merge the "basex" and "basex-api" projects, as those are tightly connected anyway.
I think that keeping jline, tagsoup, and the like out of the core is a good idea -- they're small, self-contained, and easy to toggle.
I also think that logging is different.
Logging API selection impacts all the code that uses it. As an example: Much of the code I'm writing would be considerably shorter if working with a logging framework which supported MDC; there would be no need to put the current connection info into each logged string by hand, for instance, if it simply were placed in the diagnostic context and emitted as part of the defined format string without needing to be passed as part of each and every log statement.
This kind of problem can't be solved by adding a lowest-common-denominator wrapper (similar to Apache Commons Logging or, presumably, something we were to write ourselves), but *can* be solved by using an API powerful enough to provide these features on top of an implementation which lacks them. slf4j does this, providing a full-featured, consistent API which provides *all* the features, delegates them to the underlying implementation when possible, and provides its own implementations otherwise.
Hi all,
today I made some research and found why java.util.logging (JUL) is "good, bad and ugly" [1]. Now, as a developer I'm mostly concerned with the fact that JUL may pose performance impact, due to the fact that it does not support parameterized messages. Therefore, if we decide to use JUL we'll have to wrap it anyway.
On the other hand, I found that SLF4J are good enough to provide a java.util.logging.Handler implementation which uses SLF4J [2]. So, I guess we could use the power of SLF4J, even if the accepted logging mechanism is JUL.
Regards, Dimitar
[1] http://glauche.de/2009/09/09/java-util-logging-vs-slf4j/ [2] https://github.com/ceki/slf4j/tree/master/jul-to-slf4j