The suggestion is to compile against the commons-loggging *API*, but
use an SLF4j implementation in the .war file. The net result is
identical behavior and one fewer dependency.
However, lets wait to see what happens with:
http://www.nabble.com/Java-logging-in-Lucene-td20859711.html
(Hoss, i swear i had nothing to do with starting that thread)
ryan
On Dec 9, 2008, at 7:12 AM, Grant Ingersoll wrote:
I'm not sure I follow. We're going to switch to commons-logging,
but one that was written by the SLF4J people?
On Dec 4, 2008, at 4:43 PM, Ryan McKinley wrote:
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
