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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
