Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app1

Proposals Table of Contents Last edited on Jan 20, 2001 9:26 pm


Add comments at BetterLoggingDiscussion, please.


Chris McDonough


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.


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.


Code (a candidate release named EventLogManager is here)



Help system topics

View source BetterLogging
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org