Hello Andrea
You comments are always welcome :)
Andrea Aime a écrit :
> I see that in order to redirect a package one has to
> go through Logging.getLogging("my.package.name").setLoggerFactory(xxx).
> This allows, as far as I can tell, to use a different logging subsystem
> for different packages. Not sure this is needed, but anyways, what's the
> way to redirect everything to a specific logger? Would
> Logging.getLogging("").setLoggerFactory(xxx) work?
Me too I'm really not sure that it is needed, but I did that mostly in order to
preserve compatibility with the old Logging.redirectToCommonsLogging() behavior.
Yes, Logging.getLogging("").setLoggerFactory(xxx) should work. Or you can also
use the shorthand Logging.ALL.setLoggerFactory(xxx). Or, if you want to use the
predefined loggers, Logging.ALL.setLoggingFramework(LoggingFramework.LOG4J).
> 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.
> Log4JLogger.log(Level, Message, Throwable) uses a switch but I think
> it could be simplified to logger.log(toLog4jLevel(level), message,
> throwable).
Thanks, I will apply that.
> 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.
Regards,
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/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
