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)
