Actually, Tomcat does use commons in their code, at least that's what they state here: http://tomcat.apache.org/tomcat-6.0-doc/logging.html:
Tomcat 6.0 uses Commons Logging throughout its internal code. They also state the core issue quite clearly: > The default implemenatation of java.util.logging provided in the JDK is > too limited to be useful. A limitation of JDK Logging appears to be the > inability to have per-web application logging, as the configuration is > per-VM. Paraphrasing what follows, there is no way in the default JDK implementation to have per-classloader properties files which enables easy redeployment friendly webapp configuration; and this is *the* core issue. It's not that JDK logging does not provide all the logger/appender features/implementation that log4j or logback provide, it is the impossibility to configure it from/for a webapp consistently & independently of the container. Some of us dont have control over the JVM configuration and are basically asked to produce self-describing webapps configuration wise. In these kind of (big) environments, IT usually has been setting some rules; they have made the choice of a container, handle war deployment, application start/stop, security and space/resource allocation (db or file space) but do *not* want to deal with per-webapp configurations and even less so start a JVM with specific parameters. They are acting as webapp hosters which is their (cost/efficiency conscious) way to compete with outsourced apps. Debatable solution but factual nevertheless. JDK logging as it stands, does not allow self-sufficient container agnostic reloadable webapps, that's also a fact. I respect the idea that using the platform API should always be the default choice when there is one; on this topic, the platform does not provide a solution. It can be argued that if JDK logging is not covering the practical need, we can still file bugs/jsr etc but knowing that there is a "common" solution (no pun intended) that is more or less 38 lines of code away and used by so many, the current strong position in favor of the least practical solution is difficult to understand. Let's bless open source for giving us options even when we don't agree. solr-548: +1 :-) Shalin Shekhar Mangar wrote: > > +1 > > Thanks for the links Hoss, I personally wouldn't prefer to use a framework > for something built into Java itself. Infact, this discussion prompted me > to > think about why Tomcat is not using commons-logging if it is such a great > thing. > -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p16894713.html Sent from the Solr - Dev mailing list archive at Nabble.com.
