Andrea Aime a écrit :
> Yep. I looked at the updated page and I still have two considerations to
> make:
> * Logging needs the log factory. What holds it? If GeoTools we need
> a GeoTools.getLogFactory() method so that Logging can grab it.
> If Logging we need a Logging.setLogFactory(xxx) that GeoTools will
> delegate to
I propose to put the code logic (including holding the LogFactory) in Logging,
and shortcuts in GeoTools. The purpose is to keep related code (loggings)
together and avoid the GeoTools class to grown indefinitely with code that mixe
different concerns.
Note that Java library already do that. Some java.lang.System methods are just
shortcuts toward other methods spread in the library. For example:
System method --> is a shortcut for
--------------------------------------------------
System.gc() --> Runtime.getRuntime().gc()
System.exit(int) --> Runtime.getRuntime().exit(int)
System.inheritedChannel() --> SelectorProvider.provider().inheritedChannel()
etc.
> * CommonHandler and co are @since 2.4. Can't we just delete them instead
> of deprecating?
I have no objection. CommonHandler is package-privated anyway (if I remember
correctly). Some of its code may be recycled as the basis for CommonLogger (or
whatever its name) however.
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
