: FWIW, Hoss, I don't think your main argument for JUL stands anymore (I finally : got caught up on the archives). Namely, Solr is used in embedded situations : much more now and it should no longer be assumed that it is in a standalone : servlet completely isolated from the rest of the world. I do agree on Commons
I wouldn't really say that was my main argument ... but that certainly was *an* argument, and i agree it's not as applicable now as it was in the past. My *main* argument was, and still is... >> Ultimately my main point is that all Servlet Containers already *have* >> to deal with JDK logging -- it is 100% safe to use, we don't have to >> worry about dependencies, or classpath issues; the Container takes care >> of all that. Further: many servlet containers *also* make dealing with >> code that uses multiple logging frameworks painless and configurable in >> a singlurar way -- they are already solving that problem for >> applications in general, so we don't really need to go out of our way >> to do anything special for Solr. There may be servlet containers that don't do a particularly good job of dealing with JUL (aka: JDK logging) but that is their deficiency, not Solr's. Any other logging framework, abstraction, or intermediate API we might decide to use introduces a dependency which *may* have classpath issues, *may* have class version conflict issues (if the servlet container already uses differnet version), or *may* screw with the ability of servlet containers to manage logging configuration. (i won't name names, but i've seen some logging "bridges" that muck with handler registrations in the LogManager API to the point that they break otherwise fully functional Context aware LogManagers with nice configurations just be being included in a war file) It really just doesn't seem worth it to me. -Hoss
