Graham Dumpleton wrote: > Where does setting up 'logging' module configuration fall in all of > this and who/what should handle it?
I'm not sure. What I did with paster serve was expedience, I'm not sure it's right. I guess paster serve technically also sets up the process, not just the server (which might justify things like --reload for the reloader, which is really process-wide). > I ask as I note that in the documentation for Pylons logging it says: > > """paster, when loading an application via the paster serve, shell or > setup-app commands, calls the logging.fileConfig function on that > specified ini file if it contains a 'loggers' entry. > logging.fileConfig reads the logging configuration from a ConfigParser > file.""" > > So, the paster serve is doing special setup for Pylons WSGI > components. Without knowing this magic is required, when you take a > Pylons WSGI component to another WSGI server, the logging doesn't work > as expected. To get it to work one has to duplicate the special things > that paster serve is doing in some way. It's just using logging.fileConfig, though apparently we backported Python 2.5's logging.config module. Stuff ends up in paster serve usually because I don't know where else to put them. Of course applications could take options to setup the configuration on their own (e.g., paste.translogger sets up logging, since without logging it's useless). This lets applications be a little more lazy, which is kind of what the logging module encourages (but only kind of). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
