Martin Desruisseaux ha scritto: > Hello Andrea >> I also noticed that Logging has a getLogger(name) but not a >> getLogger(name, bundle). It seems there is nothing in GeoTools using >> the latter, yet I'm wondering if that may need to be provided or >> not (in fact I've found just one usage of the latter in the entire >> java api, in the corba packages). > > There is two ways to localize loggings: > > 1) Provide a resource bundle explicitly at every Logger.logrb(...) method > calls, or Logger.log(LogRecord) with LogRecord.setResourceBundle(...) > called before. > > 2) Provide the resource bundle once for ever when invoking > Logger.getLogger(name, bundle). The logger will then automatically tries to > localize every logged message. It performs as if the explicit logrb methods > were invoked (as in way 1), except that the bundle is added automatically > with the value specified at getLogger(name, bundle). > > In GeoTools, I use only way 1 (which should work well with current > org.geotools.util.logging package). The reason is: > > - Not every localized message use the same ResourceBundle for the same logger. > Way 1 allows to specify a ResourceBundle on a case-by-case basis, while way > 2 specifies a ResourceBundle for the whole logger. > > - Some messages are not yet localized at all, so I don't want Logger to tries > to localize them. > > Nevertheless I have spent a few time trying to get LoggerAdapter to supports > way > 2. It is doable, but would increase LoggerAdapter complexity and decrease a > little bit the performance. The reason is that current LoggerAdapter > implementation hold no configuration at all - the configuration is completly > stored on the wrapped side (Log4J, commons-logging...) and every Java logging > configuration is totally ignored. If we take in account the Logger > ResourceBundle, then I introduce one Java logging configuration not hold on > the > Log4J side. In order to get LoggerAdapter to use that kind of information, I > need to add helper private fields, "synchronized" statements, etc. > > This is equivalent to the "stateless" / "statefull" tradeoff. Current > LoggerAdapter is stateless. Adding supports for logger-wide ResourceBundle (as > opposed to case-by-case ResourceBundle already supported) would make it > statefull. The same applies to java.util.logging.Filter, which are currently > not > supported by LoggerAdapter. > > I choosed the tradeoff on the assumption that the vast majority of logging > don't > go beyong the Logger.info(...), Logger.warning(...) etc. convenience methods. > However if we want to supports Filter and Logger-wide ResourceBundle we could > (maybe in a "statefull" LoggerAdapter subclass, so implementor can choose). > Note > that in the particular case of Log4J, we may be able to map the ResourceBundle > and Filter to equivalent Log4J constructs, which would allow us to keep the > Log4JLogger stateless.
Thanks for the explaination. As far as I'm concerned, the current code is ok.. mine was more a curiosity since I saw the other way to grab a Logger. Let's add support for that syntax if/when someone needs it. >> I was also wondering how to implement the user code switch (since I have >> to do the same in GeoServer). We have to turn every Logger.getLogger( >> into a org.getoools.util.Logging.getLogger(, but taking into account >> that Logger.getLogger( may have been split into multiple lines and >> with multiple spaces between the relevant parts. >> The following regular expression seem to be a good match for our needs: >> Logger\s*\.\s*getLogger\s*( > > Yes, this is exactly the regular exception that I planned to use. > > >> I think I can write a little java app that does process every java file >> with the above and perform the switch. Given the java files aren't big, >> I can just load them into memory as one big string, do a replaceAll, >> and save back. My only concern is about newline and encoding >> preservation... newlines should be kept, I hope there is a way to >> guess the original file encoding and force the writer to use the >> same. Suggestions? > > I was planning to use the Ant task for that (forget the name, but I have it > somewhere) which performs that very well... I will try it on the Geotools code > base soon and tell what I get. Hmmm, maybe this one? http://ant.apache.org/manual/OptionalTasks/replaceregexp.html 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
