"Graham Dumpleton" <[EMAIL PROTECTED]> writes: > Either way, to get the flexibility you want, user code still has to do > the association of a log handler to a specific logger at some point, eg. > preferably in a PythonImport module and only once. Adding a default > apache log handler against "mod_python" was to serve as an example > and possibly as a convenience when wanting to quickly put stuff > together.
There's a logging way to do it and a mod_python way to do it. I don't care really. I find my system preferable for the reasons I stated before (you're PythonImport module is really the syntax I was talking about earlier). But if it gets it into the distrib that's fine. >> One major benefit of logging is that it is hierarchial. The reason >> that I wanted the glue in the first place is that I have app code that >> I want to interface to the web. The app code uses logging so it's >> natural to try to make the logging go through Apache. >> >> But I wouldn't want to have to change all my loggers to use the new >> handler... that would be significant effort. > > It may well be if you are already using this scheme whereby you have > separate log handlers for each request with uniquely named loggers for > each request/thread as well. I would say that that isn't an ideal design > to begin with. The code I suggested mean't request objects and threading > were handled transparently. This would simplify your code such that it > could use the same logger name all the time. You then only have to have > in one place the association of log handler to logger. The code would > be simpler to understand then. No, no, no. I don't want to use the same logger all the time. logging is *supposed* to use many loggers. There is no programming constraint that requires unique logger names for requests (I realise I may have implied that - it is not so). But it is useful when you want to narrow a stream of logging down to a particular request. In even a moderately sized system using loggers each method would have it's own logger. The utility of mod_python/apache logging glue is that it allows you to add the handler to the base logger and get all your code logging to the right place without changing it. So you have some nice code that has unit tests and runs nicely outside of mod_python and then you have some handler code that maps it into mod_python. And the logging in all of that code just works magically because the mod_python/handler maps python logging to apache logging. >> Your system *is* useful for more casual logging in the mod_python >> context, say in an add-on handler framework. >> >> But such frameworks could take the time to do their own logging >> integration in whatever way makes sense for them. > > You are starting to make good points for why logging shouldn't be in > mod_python to begin with. That is, that a user is always probably > going to want to handle it in some special way, making it very hard > to provide a generic solution. :-) I didn't say that. I said the add on frameworks would probably want to do it themselves. Your system will cause people not using add on frameworks to either use the default provided logger all the time or to add a PythonImport to map your handler onto the loggers. But I don't really care - if your code is can get into mod_python so their is some standard glue for mapping logging into apache then that's great. Nic
