Andrea Aime a écrit :
> That would not solve the problem. The problem is that building logging
> messages is expensive, so lots of code has stuff like:
>
> if(LOGGER.isLoggable(Level.FINE)) {
> // do expensive log message building
> }
Thats the same. When I wrote "override java.util.logging.Logger" methods, I mean
override all of them, including isLoggable (pseudo-code, I don't remember the
exact API):
boolean isLoggable(Level level) {
switch (level) {
case INFO: return commonLog.canLogInfo();
// etc.
}
}
> Martin, I have the impression I'm not getting my point thru. Whatever
> VM wide solution you come up with is not acceptable. Whatever solution
> that requires to play with class loaders is not acceptable either.
The VM-wide stuff is at LogManager level only - everything else is not VM wide.
If specifying a -Djava.util.logging.config.class is not acceptable, we can
ignore LogManager and use a custom 'getLogger' methods in Geotools. Everything
else can stay unchanged.
> Seems like a good solution... is there any way I can control the
> creation of those loggers so to assign the right logging level?
> They need to answer to LOGGER.isLoggable(Level.XXX) in a way that
> reflects the log4j configuraton file.
There is no need to assing their logging level. See above code snippet.
Everything is redirected to common-logging, including 'isLoggable'.
Martin
-------------------------------------------------------------------------
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/_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
