[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/Transience/TransientObject.py Merge from 2.7 branch:

[Chris McDonough]

On Thu, 2004-05-20 at 17:08, Fred Drake wrote:
> On Thursday 20 May 2004 04:56 pm, Chris McDonough wrote:
>  > - The 2.7 branch still uses zLOG and having two separate
>  >   implementations of the module (one which uses the logging module,
> 
> But 2.7.x is using the logging module as a backend for zLOG, so it's not out 
> of the question to use logging directly.  A little tedious given that the 
> 2.7.x zLOG always writes events to the "event" log, while the 2.8+ zLOG does 
> a nicer (IMO) job of mapping zLOG "facilities" to logging-module loggers.

Good point.  That said, I'm not too concerned about doing this.. this is
a seriously obscure module.  Once I have enough confidence that it works
reliably under high load in production for real users, I will probably
just remove the debug logging code entirely.  It's convenient to leave
it in there for my own testing purposes until that day arrives.  I
wouldn't sweat it much, there are bigger fish to fry! ;-)

>  > - Currently it's not possible to filter by subsystem when writing
>  >   out a log, so I'd need to use grep or something to filter just
>  >   the TOC debug output.  I don't much want to bother. This
>  >   should probably be fixed.
> 
> That's really a matter of configuration for 2.8+; I think it'll be fairly easy 
> to deal with.  The <eventlog> section of the configuration file describes 
> handling for the root logger; child loggers inherit that behavior.  If the 
> <evenlog> section allows additional logger-specific sections, output for 
> specific subsystems can be handled specially.  I've been thinking of 
> something like:
> 
>   <eventlog>
>     level info
> 
>     <log>
>       name mysubsystem
>       level debug
>       # maybe even have some logger-specific handlers as well
>     </log>
> 
>     # global handlers go here
>   </eventlog>
> 
> This would be fairly easy to make part of the common logging package 
> configuration supplied by ZConfig; any schema that uses that would be able to 
> use this without changes to the schema.  Existing configuration files would 
> not be affected as well.

That sounds fine to me.

It also makse sense to me (without digging around in the logging module
impl to see if the model fits the proposed config style) to add/allow a
"subsystem" key to the abstract log handler class that identifies a
particular subsystem.  This also wouldn't be backwards-incompatible if
the default was just "log all subsystem output".

Something like...

<eventlog>

  level info
  <logfile>
     level info
     path $INSTANCE/log/event.log
  </logfile>
  <logfile>
     level debug
     subsystem Transience
     path $INSTANCE/log/transience-debug.log
  </logfile>
</eventlog>

I suspect this doesn't fit the logging module's way to want to do
things, however, but FWIW it seems to me a clearer way to express it to
a user of the config (I know it "fits my brain" anyway).

- C