Sure, I have no objections to something like that. I will note that we didn't see any cases where this was actually being done in the GeoTools or GeoServer codebases.
Torben On Thu, Oct 25, 2018 at 5:09 PM Jody Garnett <jody.garn...@gmail.com> wrote: > Technically people can use the String approach to make loggers on a > specific "topic" like rendering, rather than by implementation (which is > what package is documenting). > > Perhaps a getTopic( final String topic ) > > Using "topic" as "subject" could be mistaken for the "subject" class being > logged. > -- > Jody Garnett > > > On Thu, 25 Oct 2018 at 16:07, Torben Barsballe < > tbarsba...@boundlessgeo.com> wrote: > >> The org.geotools.util.logging.Logging class provides two public methods >> to get a logger: >> >> - public static Logger getLogger(final Class<?> classe) >> - public static Logger getLogger(final String name) >> >> The latter is primarily used to provide a package name manually, while >> the former infers the package name from the package of the provided class. >> >> To (1) simplify the GeoTools repackaging, (2) simplify the Logging API >> and (3) reduce the likelihood of incorrect packages being printed to the >> log, we would like to remove all usages getLogger(final String name) >> (replacing with invocation of the Class method) and deprecate the method, >> for future removal (or at least switch to private). >> The intent to do this concurrent with the GeoTools repackage happening >> this week. >> >> Does anyone have any objections, arguments for keeping the String method, >> or other comments? >> >> Torben >> _______________________________________________ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
