How to package a logging.config file?

[Vinay Sajip]

On Jul 15, 3:04 pm, Matthew Wilson <m... at tplus1.com> wrote:
> On Mon 14 Jul 2008 09:25:19 AM EDT, Vinay Sajip wrote:
>
> > Is your package a library or an application? If it's a library, you
> > should avoid configuringloggingusing a config file - this is because
> >loggingconfiguration is process-wide, and if multiple libraries use
> > fileConfig to configure theirlogging, you may get unexpected results.
>
> I thought that the point of usinglogging.getLogger('foo.bar.baz') was
> to allow each module/class/function to choose from the available
> configurations.
>
> So, I can define a really weird logger and still be a good citizen.
>
> As long as I don't tweak the root logger, is it safe to use a config
> file?
>
> Matt

The reason why using fileConfig in libraries is problematic is that
fileConfig assumes it does the entire logging configuration. Whenever
fileConfig is called, any loggers which are not explicitly mentioned
in the config file (but are present in the logging system) are
disabled. (They are not actually removed, since there may be still-
running threads that have references to them.) You may think this is
odd, but it's only because fileConfig was never intended for
incremental configuration, only for a one-off configuration. So, a
fileConfig'd configuration is meant to completely replace the existing
configuration.

So - you can use hierarchical naming of loggers to avoid stepping on
other loggers - for example, prefixing with the company domain name if
there's a possibility of use outside the company (in the same way as
Java packages use e.g. com.sun.XXX for Sun's proprietary Java
packages, or com.ibm.YYY for IBM's proprietary packages). However, I'd
advise against using fileConfig in library code, as it is likely to
disable already-instantiated loggers in other library packages.

Best regards,

Vinay Sajip