: Actually I see the argument made in the last paragraph very much in : favor of using it in Solr. Solr is intended to be used with other : applications, which will very likely use different logging frameworks.
Solr is first and foremos an application, run in an application server -- it interacts with other applications via webservice-ish APIs, which may or may not even be in Java. From that standpoint, Solr does not fit Waldhoff's criteria: "If you're building a stand-alone application, don't use commons-logging" Solr can/is also be(ing) used as a framework for JAva applications, that want Lucene at their core, but like having some of the structure Solr provides -- even in this standpoint, Waldhoff wdoes not seem to recommend commons logging: "If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging." The one case Waldhoff recommends commons logging, certainly doesn't apply to Solr: "a tiny little component that you intend for other developers to embed in their applications" : applications and webcontainers. As I see it java.util.logging is : configured through a properties file in $JAVA_HOME/jre/lib. Which not : all that nice, other logging frameworks are more flexible to configure : and use. JDK logging can be configured in a lot more ways then just a file in $JAVA_HOME/jre/lib ... i'm not trying to be rude here, but that comment leads me to believe you understand less about how JDK logging works then i do about how commons loggign works. specificly: JDK logging actually has all of hte mechanisms in it so that if you wnated to use log4j as the underlying implementaiton, you could do so by implementing a few classes and setting a system property at run time -- as i understand it, TomCat and many other servlet containers already do this, so that applications they run which use JDK logging get the log configuration from their main log files. : The added dependency is just one jar (apache project too), which is not : a to high price to pay for the benefits pointed out before. I don't remember seeing any specific benefits listed except that it would let people choose the underlying logging framework, as i've mentioned this is possible with JDK logging) -Hoss
