Well, FWIW, if you want to do this, here's a zope.conf incantation that sends all event and access log output to stdout: <eventlog> level all <logfile> path STDOUT level info </logfile> </eventlog> <logger access> level WARN <logfile> path STDOUT format %(message)s </logfile> </logger> Then you could use multilog to figure out which is which (somehow), and I think all is well. On Thu, 2004-02-12 at 17:42, Jamie Heilman wrote:
Chris McDonough wrote:
But Jamie what would you have done wrt to logging to make it not so "horrendously overcomplicated"? And what does this have to do with runzope?
It doesn't have anything to do with runzope, it has to do with the daemontools service model, whereby you have a program of some type which is "daemonized" and taken care of by supervise and it simply writes its logs to stdout which is connected to a supervised multilog process that handles all the rotation, post-processing, and other mumbo-jumbo you might want to do, as a seperate user, in a seperate process, with seperate resource limits. Hurray for security. Zope doesn't fit particularly well into that model because it wants to handle all the log rotation and all that junk itself. Which, IMHO, is a design flaw, but not a particularly big deal as its easy enough to work around if you really want to. Zope's logging, and indeed the entire python logging module, is really just far too much indirection for me to stomach. I understand why people wanted it, I understand why programmers like it, but it doesn't really excite me in the context of this particular application.