[Zope] how do you write to stupid log file?
Johan Carlsson
johanc@easypublisher.com
Tue, 15 Jul 2003 10:49:00 +0200
Stefan H. Holek wrote:
> Try this:
>
> from zLOG import LOG, INFO
> LOG('MyProduct', INFO, 'My message')
>
> Zope must run in debug mode for messages to appear in the event log.
You can also import and use other severities. If I recall correctly
everything non-negative will always be written to the stupid log file?
(so INFO will always out put to SLF)
"""General logging facility
This module attempts to provide a simple programming API for logging
with a pluggable API for defining where log messages should go.
Programmers call the LOG function to log information.
The LOG function, in turn, calls the log_write method to actually write
logging information somewhere. This module provides a very simple
log_write implementation. It is intended that applications main
programs will replace this method with a method more suited to their needs.
The module provides a register_subsystem method that does nothing, but
provides a hook that logging management systems could use to collect
information about subsystems being used.
The module defines several standard severities:
TRACE=-300 -- Trace messages
DEBUG=-200 -- Debugging messages
BLATHER=-100 -- Somebody shut this app up.
INFO=0 -- For things like startup and shutdown.
PROBLEM=100 -- This isn't causing any immediate problems, but deserves
attention.
WARNING=100 -- A wishy-washy alias for PROBLEM.
ERROR=200 -- This is going to have adverse effects.
PANIC=300 -- We're dead!
Also, looging facilities will normally ignore negative severities.
To plug in a log handler, simply replace the log_write function
with a callable object that takes 5 arguments:
subsystem -- The subsystem generating the message (e.g. ZODB)
severity -- The "severity" of the event. This may be an integer or
a floating point number. Logging back ends may
consider the int() of this valua to be significant.
For example, a backend may consider any severity
whos integer value is WARNING to be a warning.
summary -- A short summary of the event
detail -- A detailed description
error -- A three-element tuple consisting of an error type,
value, and
traceback. If provided, then a summary of the error
is added to the detail.
The callable object can provide a reinitialize method that may be
called with no arguments to reopen the log files (if any) as part of a
log-rotation facility.
There is a default stupid logging facility that:
- swallows logging information by default,
- outputs to sys.stderr if the environment variable
STUPID_LOG_FILE is set to an empty string, and
- outputs to file if the environment variable
STUPID_LOG_FILE is set to a file name.
- Ignores errors that have a severity < 0 by default. This
can be overridden with the environment variable STUPID_LOG_SEVERITY
"""
def LOG(subsystem, severity, summary, detail='',
error=None, reraise=None):
"""Log some information
The required arguments are:
subsystem -- The subsystem generating the message (e.g. ZODB)
severity -- The "severity" of the event. This may be an integer or
a floating point number. Logging back ends may
consider the int() of this valua to be significant.
For example, a backend may consider any severity
whos integer value is WARNING to be a warning.
summary -- A short summary of the event
detail -- A detailed description
error -- A three-element tuple consisting of an error type, value, and
traceback. If provided, then a summary of the error
is added to the detail.
reraise -- If provided with a true value, then the error given by
error is reraised.
"""
--
Johan Carlsson Tel: + 46 8 31 24 94
Colliberty Mob: + 46 70 558 25 24
Torsgatan 72 Email: johanc@easypublisher.com
SE-113 37 STOCKHOLM