Logging issues on the trunk
There are a few remaining issues regarding logging in the svn trunk.
The ReopenableFileHandler.__init__ method in Mailman/loginit.py calls
logging.FileHandler.__init__(self, filename, mode, encoding)
This method only allows the instance, filename and mode arguments. The encoding argument throws a TypeError exception.
The 'locks' log is missing from the LOGGERS tuple in loginit.py
Mailman/LogFile.py still references Mailman.Logging.StampedLogger This is tricky if we want to maintain its current ability to be used outside of Mailman.
I *think* we could change
try: from Mailman.Logging.StampedLogger import StampedLogger _logfile = StampedLogger('locks')
to
try: from Mailman import loginit _logfile = logging.getLogger('mailman.locks') _logfile.write = _logfile.info
where the import of loginit is just to see if it throws the exception. I'm not sure if we ever need to actually call
loginit.initialize()
as in most if not all cases, this has already been done by some superordinate importer of LogFile.
Many of the scripts/* files contain
from Mailman.Logging.Utils import LogStdErr and LogStdErr('error', 'name')
I think these can just be deleted as the scripts/driver script does the Mailman.loginit.initialize()
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 2006-04-25 at 14:46 -0700, Mark Sapiro wrote:
There are a few remaining issues regarding logging in the svn trunk.
The ReopenableFileHandler.__init__ method in Mailman/loginit.py calls
logging.FileHandler.__init__(self, filename, mode, encoding)
This method only allows the instance, filename and mode arguments. The encoding argument throws a TypeError exception.
Looks like that's a Python 2.3/2.4 compatibility issue. Dang. Okay, I'll figure out a workaround for that.
- The 'locks' log is missing from the LOGGERS tuple in loginit.py
Thanks, I'll add that.
Mailman/LogFile.py still references Mailman.Logging.StampedLogger This is tricky if we want to maintain its current ability to be used outside of Mailman.
I *think* we could change
try: from Mailman.Logging.StampedLogger import StampedLogger _logfile = StampedLogger('locks')
to
try: from Mailman import loginit _logfile = logging.getLogger('mailman.locks') _logfile.write = _logfile.info
where the import of loginit is just to see if it throws the exception. I'm not sure if we ever need to actually call
loginit.initialize()
as in most if not all cases, this has already been done by some superordinate importer of LogFile.
That sounds about right. We might want to parameterize the actual logger name at the top in case someone wants to change that. OTOH, I'm not aware of anybody else actually using the LockFile.py implementation outside of Mailman.
Many of the scripts/* files contain
from Mailman.Logging.Utils import LogStdErr and LogStdErr('error', 'name')
I think these can just be deleted as the scripts/driver script does the Mailman.loginit.initialize()
That sounds right too. Thanks for finding these Mark -- I'll attack those tonight. I'm also working on a diff that will replace getopt with optparse and will put the bulk of the bin/* and cron/* scripts as modules under Mailman.bin. There will be a symlink from bin/mmshell to the individual scripts, and mmshell will look at sys.argv[0] to figure out which module to run. The nice thing about this is that we won't have to re-run configure every time one of those command line scripts change, but only if mmshell changes.
-Barry
Barry Warsaw wrote:
On Tue, 2006-04-25 at 14:46 -0700, Mark Sapiro wrote:
The ReopenableFileHandler.__init__ method in Mailman/loginit.py calls
logging.FileHandler.__init__(self, filename, mode, encoding)
This method only allows the instance, filename and mode arguments. The encoding argument throws a TypeError exception.
Looks like that's a Python 2.3/2.4 compatibility issue. Dang. Okay, I'll figure out a workaround for that.
It doesn't seem to me to be 2.3/2.4 compatibility. It doesn't work for me with 2.4.1 and it didn't work for the poor soul who reported on mailman-users that he tried building from source for the first time and used the SVN trunk, and he has 2.3.5. There's no indication of an encoding argument in either <http://docs.python.org/lib/node347.html> or <http://docs.python.org/dev/lib/node391.html>
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, 2006-04-26 at 19:20 -0700, Mark Sapiro wrote:
Barry Warsaw wrote:
Looks like that's a Python 2.3/2.4 compatibility issue. Dang. Okay, I'll figure out a workaround for that.
It doesn't seem to me to be 2.3/2.4 compatibility. It doesn't work for me with 2.4.1 and it didn't work for the poor soul who reported on mailman-users that he tried building from source for the first time and used the SVN trunk, and he has 2.3.5. There's no indication of an encoding argument in either <http://docs.python.org/lib/node347.html> or <http://docs.python.org/dev/lib/node391.html>
Oh nice. From scanning the logs, it appears as though the encoding stuff appeared in 2.4.2. Bad, bad, bad, bad, bad.
In any event, we need to make this stuff work with 2.3 so I'll fix that, probably by writing a complete reopenable file handler from scratch. That'll let us pass the error handling to the codec open too, which we definitely need.
Won't happen in the about to go in next patch, but hopefully I will get to it tonight.
Also, note to those running the trunk: development is picking up and it's very possible that things may be unstable for a bit. I'm going to try to get the new tracker up as quickly as possible, but for now, just let us know here on this mailing list and we'll get to it as soon as possible.
Also, if you're interested in working on Mailman 2.2, let us know. I'd like to get more people involved!
-Barry
participants (3)
-
Barry Warsaw
-
Fil
-
Mark Sapiro