Hi all, as some of you may have notice, we still have logging issues in GeoServer land due to the way the java logging -> commons logging bridge is implemented.
Me and Martin have had a discussion on the topic on the GeoServer ml, and it seems we've found a satisfactory solution for the both of us. Full thread here: http://www.nabble.com/Some-consideration-on-GeoServer-logging-tf4683523.html The solution will involve changing the way GeoTools grabs the loggers, as described in this issue: http://jira.codehaus.org/browse/GEOT-1545 Now, this is not a change in the API but a change in the way we do things it is, in that we'll need to setup a convention on how loggers are grabbed and describe it in the developers guide. Seems like something that needs to be turned into a proposal. At the moment codehaus is in troubles with confluence so I cannot write the proposal right away, but I'll write one asap. In the meantime I'd appreciate if people could have a look at the thread and at the jira issue and make up their mind for a voting on the next GeoTools meeting. And oh, to make it clear, what I'm proposing is to do the above switch in 2.4.x too (otherwise it would be useless for GeoServer for at least another 3-4 months). I believe what I'm asking is not unreasonable, since the only change needed is basically an import statement and a Logger.getLogger(xxx) to GT2LogFactory.getLogger(xxx) (the name of the actual log factory class is in fact yet to be determined). Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
