Not knowing what subsystem was for, I just filled it with __name__. So a log entry looks like this: ------ 2000-06-14T20:05:22 INFO(0) Products.ZScheduler.Loggerr Trigger event: http://eagle:8080/zev3 Trigger time: 1970/12/31 16:00:00 US/Pacific Bang! ------ If you need to parse this, you can determine that it came from ZScheduler, you can determine which event was triggered, and you can see the output of the event, if any (Bang!, in this case). Is that good enough for any applications you have in mind? -- Loren
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Stuart 'Zen' Bishop Sent: Thursday, June 15, 2000 13:52 To: Loren Stafford Cc: Loren Stafford; zope-dev Subject: RE: [Zope-dev] Logging for ZScheduler?
On Thu, 15 Jun 2000, Loren Stafford wrote:
It would be a good idea if there was a field in the ZEvent that defined the subsystem used in the zLOG call.
I didn't follow your point here. By "subsytem" do you mean which logger in the loggers tuple? Then do you mean that different ZEvents could log to different loggers? Why would this be a "good idea", I mean, do you have a use case in mind?
from zLOG.py: def LOG(subsystem, severity, summary, detail='', error=None, reraise=None):
The first argument specifies a subsystem, which is passed to the logging implementation. A logging subsystem may choose to ignore log messages from particular subsystems, or perform special actions (eg. if a critical error has occured in the ZScheduler subsystem, page the sysadmin). By allowing an individual ZEvent to override the subsystem reported, you can gain even more control.
-- Stuart Bishop Work: zen@cs.rmit.edu.au Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au Computer Science, RMIT University