|
Add comments at BetterLoggingDiscussion, please.
Contact
Chris McDonough
Problem
Zope has a basic application-level logging system which is
generally called in product code such as "from zLOG import LOG,
ERROR; LOG(subsystem, SEVERITY, summary)". The services
exposed by the zLOG module are very basic, and are not
configurable. They should be configurable and extensible. It is
also desireable to be able to abstract logging details out of
application-level code. Zope should provide a configurable
"default" log configuration, but it should also let Product
developers override this default configuration within their
Products if they choose.
Proposed Solutions
A "log manager" facility (much like the skeleton of one in the
ZLoggerx.py file as exposed by the log_write method) must be
constructed. This log manager should be responsible for
deciding where messages go (ie. to which "loggers"). This
"log manager" should be accessible and configurable via the Zope
Control Panel or a configuration file. The log manager facility
needs to have an API for the registration of new loggers and
consumers, and an API for the configuration of its
decisionmaking logic.
Individual "logger" facilities (e.g. syslogLogger, fileLogger)
must be constructed or refactored to be configurable outside of
their source code. "Loggers" main jobs should be to determine
whether or not to log a particular message based on the
content of the message. The loggers must conform to an API
which allows its decisionmaking logic to be manipulated.
Facilities should be provided which allow a Product developer to
have a "default logging configuration" on a per-product basis.
For example, a Product developer could choose to override the
"Zope default" logging configuration with his own by registering
(as a "consumer") properly with the log manager. Code within
this Product would then log according to this specified logging
configuration as opposed to the Zope default configuration,
Application-level product logic and Zope default logging
configuration would not need to change.
The "stupid file logger" mechanism used by the logging machinery
must be replaced and retired.
The documentation in LOGGING.txt in the docs directory needs to
be updated and should reflect whatever changes are made.
Help system topics should be made available for the log manager
and loggers.
Risk Factors
Changes made to the logging machinery might break backwards
compatibility if not thought out properly.
Products may need to expose logging configuration stuff within
their UI (much like they do with the help system). This code is
black magic to me, and I may mess it up.
The business of "registration" of consumers and new loggers badly
wants to be abstracted outside the framework of the logging
system. We may duplicate effort if a generic registration system
gets constructed after this one.
Scope
The first cut at this won't include any UI stuff, and will not
allow Product developers to override the Zope default logging
configuration. First, the stupid file logger will be retired and
replaced with something more configurable. An API will be derived
from it. Then the log manager will be devised and an API will be
derived from that.
Deliverables
Code (a candidate release named EventLogManager is here)
Examples
LOGGING.txt
Help system topics
|
