To a certain extent SLF4j makes this decision a fairly small one, namely what API do you want to code to inside SOLR and what jars do you want to ship as a part of the distribution. It doesn't really matter if you pick commons-logging, log4j or slf4j; all have drop in replacements via SLF4j. They also have one for java.util.logging however it requires custom code to activate since you can't replace java.* classes. End users get to do pretty much whatever they want as far as logging goes if you use SLF4j.
SLF4j has also updated their 'legacy' page since the last time I looked which was the ~last time this came up: http://www.slf4j.org/legacy.html We choose to code against slf4j APIs as it seemed like it was where things were going (including solr) and gave us and our customers the ability to switch to something else with minimal effort. We also ship log4j+config jars by default because it had the richest config/appender set at the time however the logback project seems like it might be catching up. (good thing we can switch with no code changes) - will -----Original Message----- From: Ryan McKinley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 4:44 PM To: [email protected] Subject: logging revisited... While I'm on a roll tossing stuff out there.... Since SOLR-560, solr depends on SLF4j as the logging interface. However since we also depend on HttpClient we *also* depend on commons- logging. This is a strange. Our maven artifacts now depend on two logging frameworks! However the good folks at SLF4j have a nice solution -- a drop in replacement for commons-logging that uses slf4j. HttpClient discussed switching to SLF4j for version 4. They decided not to because the slfj4 drop-in replacement gives their users even more options. In Droids we had the same discussion, and now use commons-logging API. So, with that in mind I think we should consider using the commons- logging API and shipping the .war file with the slf4j drop in replacement. The behavior will be identical and their will be one fewer libraries. The loss is the potential to use some of slf4j's more advanced logging features, but I don't see us taking advantage of that anyway. ryan
