[Zope-dev] Logging for ZScheduler?

[Loren Stafford]

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
>