--On Dienstag, 20. April 2004 17:19 Uhr -0400 Fred Drake fred@zope.com wrote:

...

• when adding LOG = getLogger(...) LOG.info(...) to some modules then the output is only written to the event.log but

no > longer to stdout

...

(if running in debug mode). Is this change intentional?

I'm not sure what the right approach to fixing this is. There are a couple of choices:

• In debug mode, add a new handler that dumps to standard output. This is fairly easy to code, but is inflexible.

But flexible enough for most usecase. The point is that you want to see the tracebacks on the console during the development phase. Watching the event.log with tail -f is somewhat annoying.

• In debug mode, use an alternate or auxillary logging configuration to replace or augment the <eventlog> configuration section. This is more

work up front, but keeps everything flexible.

Maybe too much overkill...not sure if one needs an academic solution here...

Andreas

On Wednesday 21 April 2004 04:48 am, Chris Withers wrote:

I'm guessing there is some kind of log-to-console logger already?

If so, why not just add that in zope.conf and comment it out when you move to production?

That would work for me, but not everyone at ZC agreed, so I've made some changes that should be good for most people; see my message to Andreas and (and Zope-Dev) for a description of how things work on the trunk now.

BTW, is there a logger in Python 2.3/Zope 2.7 that sends log entries via email? If not, I'll port MailingLogger to Zope 2.7 and see if I can make it play nice :-)

Yes, there is. You should be able to use it by adding a section like this inside your <eventlog> section in zope.conf:

<email-notifier> from Chris Withers chris@example.com to sysadmin@example.com to zope-email-notifications@example.com subject Something blew up! smtp-server mail@example.com

level error format Timestamp: %(asctime)s\nComponent: %(name)s\nLevel: %(levelname)s (%(levelno)s)\n\n%(message)s </email-notifier>

My mailer might have wrapped that long line; sorry. ;-(

Let me know if there are any problems with this.

-Fred

Fred Drake wrote:

Yes, there is. You should be able to use it by adding a section like this inside your <eventlog> section in zope.conf:

Cool :-) No more need for the MailingLogger product, provided the question below has an answer...

And there was me looking forward to writing a product that added its own ZConfig section :'(

<email-notifier>
  from        Chris Withers <chris@example.com>
  to          sysadmin@example.com
  to          zope-email-notifications@example.com
  subject     Something blew up!

Okay, how can I get the log level and exception type into the subject?

Chris

Fred Drake wrote:

That's not currently possible, though it wouldn't be hard to add. Perhaps some future ZConfig revision would add this.

Surely ZConfig alredy allows this, it's just Zope's use of ZConfig that needs to support it?

Chris

Fred Drake wrote:

The configuration of the logging is handled using a ZConfig component that's actually bundled with ZConfig itself on the Zope 2 head; it's in the package ZConfig.components.logger. This allows any project using ZConfig to use the same basic logging support; we actually have several projects using ZConfig outside the application server.

Cool. Okay, quick question for you...

I'm trying to set up some (normal python) logging so that run of the mill messages are send to a logfile while critical errors are sent via email to me. I got to:

import logging logger = logging.getLogger('X2Y') hdlr = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(process)d %(levelname)s %(message)s') hdlr.setFormatter(formatter) logger.addHandler(hdlr) if len(sys.argv)==2 and sys.argv[1]=='debug': logger.setLevel(logging.DEBUG) else: logger.setLevel(logging.INFO) hdlr = logging.SMTPHandler(*etc*) formatter = logging.Formatter('%(asctime)s %(process)d\n\n%(message)s\n\n%(pathname)s line %(lineno)d.') hdlr.setFormatter(formatter) logger.addHandler(hdlr)

...but then couldn't figure out how to say that the SMTPHandler should only deal with messages that are critical.

Any ideas?

Bringing this back on topic, I'd also be very interested in doing the same thing for Zope instances...

cheers,

Chris

I wrote:

• In debug mode, add a new handler that dumps to standard output. This

is fairly easy to code, but is inflexible.

Andreas responded:

But flexible enough for most usecase. The point is that you want to see the tracebacks on the console during the development phase. Watching the event.log with tail -f is somewhat annoying.

Understood! I've committed changes that that I think should do the trick for you.

- In debug mode, a log handler is added to the root logger that writes events to standard error. This is no longer conflated with the "startup" logging.

- When running Zope using "zopectl fg" (the best way to run things for debugging), zopectl will force debug mode to be enabled.

...

• In debug mode, use an alternate or auxillary logging configuration to replace or augment the <eventlog> configuration section. This is more

work up front, but keeps everything flexible.

Maybe too much overkill...not sure if one needs an academic solution here...

I don't know that I'd describe this as academic (most academics I've worked with considered the ability to change the code configuration enough), but if you're happy not to need it, I'm happy not to implement it. ;-)

-Fred