: > Ryan: I may not know where you live, and i may not know what you look : > like, but if you insist on goading me like this i will dedicate myself to : > answering those questions so i can come to your house and hurt you.
: game on! In case anyone is concerned for Ryan's safety: i'm only kidding (for now) : > here's my question though: if the slf4j guys have such great support for : > implementing the commons-logging api (jcl-over-slf4j.jar right?) then why : > do we need to change any code in solr? : > : > using your three bullet points: can't we skip #1, and just do #2 : > and then #3 still applies? : I'm not sure I follow... To be clear, the behavior in either case will be the : same. The question is just about what logging dependencies are required for : solr. Since we are forced to depend on the commons-logging api, it might : make sense to just use that api. by "forced to depend on the commons-logging api" you mean we indirectly depend on it because httpclient right? there's not much we can do about that. : I am totally happy to leave things as they are -- I like the slf4j API and it : seems to be getting more popular. (lucene java is even considering using it) i like your idea of shipping the jcl-over-slf4j.jar in the solr.war ... at least that way all of the httpclient log messages get piped to JUL the same way as all the solr log messages; and anyone who uses slf4j to change the output "pipeline" to go to some other logging implementation only has to do it once, and doesn't need to add jcl-over-slf4j.jar to get consistent logging. but i don't think changing the api Solr compiles against to commons-logging makes sense -- not since we're already using the least common denominator API (slf4j) We could add a new dependency tomorow that uses log4j, and ship with log4j-over-slf4j.jar; but would we then change the debate to whether the Solr code should use the commons API or the log4j API or the slf4j API? ... why bother when it's all going to go through slf4j anyway? -Hoss