Hi all,
In yet another attempt to make GeoServer logging better I find myself butting my head against geotools logging. I know that Andrea (and others) have already brought this issue up, but i need to add my voice as well.
Going beyond the controversial issue of a having a library force a particular logging implementation on an application there are other issues to consider.
The global nature of java logging makes it unusable in a servlet container where each application has its own logging requirements. Imagine applications that use the same libraries stepping all over each other with regard to logging configuration. its a nightmare. Undoubtedly the reason why most libraries use commons-logging backed by log4j.
Also configuration via a property file with java logging leaves much to be desired. One has to set a system property which means either having the user pass it in, or latching onto a system startup event and setting it programmatically. Just having a properties file on the classpath is much nicer imho.
There have been requests to switch to commons-logging before, the last one being from Andrea at foss4g last year. From what I can tell the biggest issue preventing this is logging internationalization. Without it the switch would be pretty straight forward and could probably be done with a few regular expressions. However commons-logging does not directly support support i18n from what I can tell. This is a blocker as there has been much effort put into supporting logging i18n in geotools. So i think the bottom line is that geotools will be using java logging for quite some time.
There is however some light at the end of this tunnel for those of us developing applications. Martin has written an adapter which will forward java logging calls to commons-logging. Yippee. However there are a few issues with it.
1. It does not support i18n
2. Mapping between the different log levels needs a bit of tweaking
3. It requires that java logging code that creates a LogRecord directly set the logger name, which is kind of redundant because you just pass the LogRecord to the logger anyways.
I have created a patch to remedy these issue and attached it to this issue:
http://jira.codehaus.org/browse/GEOT-1202
Feedback much appreciated, especially on how to map back and forth among the commons and java logging levels. The mapping i have come up with is:
java to commons:
FINEST -> TRACE
FINER,FINE -> DEBUG
CONFIG,INFO -> INFO
WARNING -> WARN
SEVERE -> ERROR
commons to java:
TRACE -> FINEST
DEBUG -> FINER
INFO -> CONFIG
WARN -> WARNING
ERROR,FATAL -> SEVERE
With this patch we will be able to use log4j in geoserver, yah!! However web applications that use geotools in the same servlet container will still be stuck stumbling over each other. At least we will be able to save libraries like spring and struts.
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
