NTEventLogHandl er not logging `info'?

[Jaime Wyant]

This code doesn't seem to do what I think it should do:

# python 2.3.2
# not sure of my win32 extensions version

import logging
from logging.handler s import NTEventLogHandl er
logger = logging.getLogg er("testlogger" )
handler = NTEventLogHandl er("testlogger" )
logger.addHandl er(handler)
logger.info("Th is is a test")
I expected to see an `information' message in my `Application' event
log. Any ideas?

Thanks,
jw

[Vinay Sajip]

Jaime Wyant wrote:

This code doesn't seem to do what I think it should do:

# python 2.3.2
# not sure of my win32 extensions version

import logging
from logging.handler s import NTEventLogHandl er
logger = logging.getLogg er("testlogger" )
handler = NTEventLogHandl er("testlogger" )
logger.addHandl er(handler)
logger.info("Th is is a test")
I expected to see an `information' message in my `Application' event
log. Any ideas?

By default, the logger's level is WARNING, because you haven't
explicitly set a level and the level inherited from the parent logger
is WARNING (this is the default value for the root logger level). So if
you add a line before the logger.info() call:

logger.setLevel (logging.INFO) # or you can use logging.DEBUG

Then you should see an entry appear in the NT Event log.

[Jaime Wyant]

I must be missing something. This is what I read from the documentation:

When a logger is created, the level is set to NOTSET (which causes all
messages to be processed in the root logger, or delegation to the
parent in non-root loggers).

:/

Thanks!
jw

On 22 Sep 2005 08:21:48 -0700, Vinay Sajip <vi*********@ya hoo.co.uk> wrote:

Jaime Wyant wrote:

This code doesn't seem to do what I think it should do:

# python 2.3.2
# not sure of my win32 extensions version

import logging
from logging.handler s import NTEventLogHandl er
logger = logging.getLogg er("testlogger" )
handler = NTEventLogHandl er("testlogger" )
logger.addHandl er(handler)
logger.info("Th is is a test")
I expected to see an `information' message in my `Application' event
log. Any ideas?

By default, the logger's level is WARNING, because you haven't
explicitly set a level and the level inherited from the parent logger
is WARNING (this is the default value for the root logger level). So if
you add a line before the logger.info() call:

logger.setLevel (logging.INFO) # or you can use logging.DEBUG

Then you should see an entry appear in the NT Event log.

--
http://mail.python.org/mailman/listinfo/python-list

[Jaime Wyant]

BTW - you're suggestion worked.

Thanks again!
jw

On 9/22/05, Jaime Wyant <pr***********@ gmail.com> wrote:

I must be missing something. This is what I read from the documentation:

When a logger is created, the level is set to NOTSET (which causes all
messages to be processed in the root logger, or delegation to the
parent in non-root loggers).

:/

Thanks!
jw

On 22 Sep 2005 08:21:48 -0700, Vinay Sajip <vi*********@ya hoo.co.uk> wrote:

Jaime Wyant wrote:

This code doesn't seem to do what I think it should do:

# python 2.3.2
# not sure of my win32 extensions version

import logging
from logging.handler s import NTEventLogHandl er
logger = logging.getLogg er("testlogger" )
handler = NTEventLogHandl er("testlogger" )
logger.addHandl er(handler)
logger.info("Th is is a test")
I expected to see an `information' message in my `Application' event
log. Any ideas?

By default, the logger's level is WARNING, because you haven't
explicitly set a level and the level inherited from the parent logger
is WARNING (this is the default value for the root logger level). So if
you add a line before the logger.info() call:

logger.setLevel (logging.INFO) # or you can use logging.DEBUG

Then you should see an entry appear in the NT Event log.

--
http://mail.python.org/mailman/listinfo/python-list

[Vinay Sajip]

Jaime Wyant wrote:

I must be missing something. This is what I read from the documentation:

When a logger is created, the level is set to NOTSET (which causes all
messages to be processed in the root logger, or delegation to the
parent in non-root loggers).

The documentation could be clearer, I agree. I will add the following
clarifying sentence to the docs:

The term "delegation to the parent" means that if a logger has a level
of NOTSET, its ancestor loggers are examined until the root is reached,
or an ancestor with a level other than NOTSET is found. In the latter
case, that level is treated as the effective level of the logger where
the ancestor search started, and is used to determine how a logging
event is handled. If the root is reached, and it has a level of NOTSET,
then all messages will be processed. Otherwise, the root's level will
be used as the effective level.

Please post a response on the list if you think the above is still not
clear enough.

[Jaime Wyant]

On 22 Sep 2005 12:23:50 -0700, Vinay Sajip <vi*********@ya hoo.co.uk> wrote:

Jaime Wyant wrote:

I must be missing something. This is what I read from the documentation:

When a logger is created, the level is set to NOTSET (which causes all
messages to be processed in the root logger, or delegation to the
parent in non-root loggers).

Thanks for your attentiveness!
The documentation could be clearer, I agree. I will add the following
clarifying sentence to the docs:

The term "delegation to the parent" means that if a logger has a level
of NOTSET, its ancestor loggers are examined until the root is reached,
or an ancestor with a level other than NOTSET is found. In the latter
case, that level is treated as the effective level of the logger where
the ancestor search started, and is used to determine how a logging
event is handled. If the root is reached, and it has a level of NOTSET,
then all messages will be processed. Otherwise, the root's level will
be used as the effective level.

Please post a response on the list if you think the above is still not
clear enough.

After re-reading the documentation I posted originally, it makes much
more sense and I feel much more stupid *smacks self in head*. Your
definition of "delegation of the parent" is right on the mark, however
I found myself having to read it a few times to have it `sink in'.

I've rewritten it below in a bit easier to read fashion (I think).

The term "delegation to the parent" means that if a logger has a level
of NOTSET, its chain of ancestor loggers are traversed until an
ancestor with a level other than NOTSET is found or the root is
reached.

If an ancestor is found with a level other than NOTSET, then that
ancestor's level is treated as the effective level of the logger where
the ancestor search began, and is used to determine how a logging
event is handled.

If the root is reached, and it has a level of NOTSET, then all
messages will be processed. Otherwise, the root's level will be used
as the effective level.

HTH,
jw