logging - slf4j?
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of message formats.
This means you don't have to wrap stuff in if( level = DEBUG ). By
default, the stuff you print out (even toString() ) isn't executed
unless that logging level is set.
logger.debug(value: {}., entry.somethingThatTakesSomeTime() );
Other projects using slf4j include apache wicket and jetty6.
Thoughts?
ryan
Re: logging - slf4j?
On 3/7/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of message formats.
This means you don't have to wrap stuff in if( level = DEBUG ). By
default, the stuff you print out (even toString() ) isn't executed
unless that logging level is set.
logger.debug(value: {}., entry.somethingThatTakesSomeTime() );
Well, it isn't quite that simple: entry.somethingThatTakesSomeTime()
will be executed in the example you provide. From what I've gleaned
by glancing at the site, it appears to be necessary to hide the calls
in the toString method of some object to delay the execution. Too bad
this isn't python or lisp ;).
I'm not particularly enmeshed in the enterprise java philosophy, but
ISTM that this type of choice matters more for frameworks and
containers than stand-alone products like Solr. I'm also loathe to
introduce dependencies unless there is a clear need.
OTOH, I'm certainly not against it if people have used it and found a
clear benefit that they believe will carry over to Solr.
-Mike
Re: logging - slf4j?
Well, it isn't quite that simple: entry.somethingThatTakesSomeTime()
will be executed in the example you provide. From what I've gleaned
by glancing at the site, it appears to be necessary to hide the calls
in the toString method of some object to delay the execution. Too bad
this isn't python or lisp ;).
sorry, bad example - it is only the toString() bit that is better. from:
http://www.slf4j.org/faq.html#logging_performance
The following two lines will yield the exact same output. However,
the second form will outperform the first form by a factor of at least
30, in case of a disabled logging statement.
logger.debug(The new entry is +entry+.);
logger.debug(The new entry is {}., entry);
I'm not particularly enmeshed in the enterprise java philosophy, but
ISTM that this type of choice matters more for frameworks and
containers than stand-alone products like Solr.
But i am using solr as a framework - not a stand alone product! The
RequestHandler / ResponseWriter framework is a great framework on its
own.
Solr is not just the .war, it is also the .jar :)
OTOH, I'm certainly not against it if people have used it and found a
clear benefit that they believe will carry over to Solr.
For me, the immediate benefit is that i could have one logging setup
rather then two. I'm integrating solr with an existing log4j based
system. I have some existing logging code I'd love to use with solr
rather then re-write a JDK logging version (SOLR-178 and other stuff)
Re: logging - slf4j?
: Is there any interest in using slf4j (http://www.slf4j.org/) rather
: then forcing folks to use JDK logging?
i'd really rather now .. JDK logging is universal (at least in all JDK
versions Solr supports) and while i have no problem adding dependencies
to SOlr if they allow for really great features, adding a dependency just
for differnet logging doesn't make sense to me.
: The nice thing about slf4j is that user can easily switch the logger
I've seen this argument against JDK logging before .. but frankly i've
never understood it -- JDK Logging is one of the few places where the JDK
really goes above and beyond to give the user hooks for controlling things
-- not just with configuration, but even with the underlying
implementation (via the java.util.logging.manager system property) if
someone doesn't like the implementation that comes with their JVM, they
can happily load in a differnet one at runtime.
: implementation. The other nice thing is its use of message formats.
: This means you don't have to wrap stuff in if( level = DEBUG ). By
: default, the stuff you print out (even toString() ) isn't executed
: unless that logging level is set.
:
: logger.debug(value: {}., entry.somethingThatTakesSomeTime() );
knowing that you really ment...
logger.debug(value: {}., entry );
...(refering to the delayed toString()ing only if the debug level
neccessitates it) this doesn't seem like a very compelling reason, since
JDK logging already supports that (via java.text.MessageFormat)
logger.log(Level.DEBUG, value: {0}., entry );
...granted, JDK logging doesn't provide the handy method alias in the case
where you want a paramterized message, but in cases where you are
concerned about the performance of toStringing an object, it's not asking
so much to use log(Level.DEBUG, ...) instead of debug(...)
-Hoss
Re: logging - slf4j?
On 3/7/07, Chris Hostetter [EMAIL PROTECTED] wrote: : Is there any interest in using slf4j (http://www.slf4j.org/) rather : then forcing folks to use JDK logging? i'd really rather now .. JDK logging is universal (at least in all JDK versions Solr supports) and while i have no problem adding dependencies to SOlr if they allow for really great features, adding a dependency just for differnet logging doesn't make sense to me. ok - i was just asking to see how you all feel about it. If I'm the only one who would like it, its obviously not worth changing. where you want a paramterized message, but in cases where you are concerned about the performance of toStringing an object, it's not asking so much to use log(Level.DEBUG, ...) instead of debug(...) damn! I was hoping an esoteric performance argument (that i don't particularly care about) would woo you!
