It still strikes me as just wrong when you have to jump through such hoops to do something as fundamental as grab a logger. I am not saying I do not support this approach, if it works it works but I would like to put in my 2 cents:
And please, before I state anything. I do not want to start another thread about java logging vs commons logging, that issue has been beat to death. However, way back when we had a discussion and it was mostly agreed to switch to commons logging. Even Martin agreed that if the rest of the developers were for the change that he would concede (correct if i am wrong here Martin). So what I am saying is I would rather see effort go into a switch to commons logging rather than the search and replace discussed above. Actually when i spec'd it out way back when most of the commons logging switch can be done with a search and replace as well. I realize that a full switch to commons logging is much more work then the proposal presented. But... two additional worries about the proposal: 1. Will it really work? It strikes me as a hack and hacks have this tendency to not actually work for every case 2. I doubt that most developers will read the full developers guide before beginning to code. And grabbing a logger using Logger.getLogger() is something that every programmer will intuitively do. My 2c. Andrea Aime wrote: > 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 > > !DSPAM:4007,4720553f277181849620573! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
