- I would not add the handler to the 'request' logger ; like Nic or Nick or Bruce said, this is not required, the 'request' logger inherits his handlers from the root logger. This would ease things a little bit.
- Anyway, my point is the same as yours : setting it up properly is far from trivial. The simplicity of the handler code should not mask the complexity of the setup.
One thing to remember : every piece of code we introduce into mod_python is a liability. We'll have to support it and I can't wait for having to solve setup problems of people asking the list "where are my log entries going ?" or "my log entries are repeated multiple times in the Apache log".
So, either we have a full treatment of all the problems this logging handler may bring, or we just have this little Pandora box lying somewhere in the contrib department, along with SQLiteSession :).
You guys must find it funny that I write this after having proposed SQLiteSession, but I think I've understood the point now :). It will be time to add random features here and there when we'll be bored to death because no one is posting to the list about any problem.
Regards,
Nicolas
2005/10/19, Jim Gallacher <[EMAIL PROTECTED]>:
Nicolas Lehuen wrote:
> 2005/10/19, Nic Ferrier <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] >>:
>
> Is everyone here called Nic[h]olas?
>
>
> Nicolas Lehuen <[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> writes:
>
> > Nic, there is something I need to understand before giving my
> advice on the
> > subject. I'm not familiar with the logging API, can you tell me
> how you
> > configure Python to use this logging implementation ? Looks like
> we have to
> > manipulate configuration object, set up handlers and so on... If
> so I guess
> > we'd have to add a word or two in the documentation on the best
> way to do
> > this in the mod_python context...
>
> Hmmm... logging is actually very simple if you want it to be.
>
> All you really have to do to use logging from Python is this:
>
> import logging
>
> # then sometime later
>
> logger = logging.getLogger()
> logger.debug("a log message")
>
>
> lot's more things are possible and the logging API is very
> configurable.
>
>
> From an Apache point of view you do need to configure the default
> logger in your handler so that it has access to the apache vhost
> logger:
>
>
> hdlr = apache_log_handler.ApacheLogHandler(http)
> logging.getLogger().addHandler(hdlr)
>
> once you've done that then any handler which descends from the default
> handler (and that's the normal way to do things) will log to Apache.
>
>
>
> Nic
>
>
> In that case, setting up the logging handler should be done by the user,
> making sure that it is set up only once per interpreter, even in the
> context of a multi-threaded MPM. It's not a trivial thing ; looks like
> this is a job for PythonImport.
Except that you won't have a server reference to get the virtual host
configuration. If you are using a custom log for each virtual host,
won't your error messages end up in the wrong log?
> So my advice is that if the set up is done by the user, then the logging
> handler should be considered as contrib. If you provide a way for
> mod_python to directly set up the handler, maybe this could be
> considered part of mod_python.
Here are some further things to consider if anyone wants to persue it.
Consider the following code:
import logging
from mod_python import apache
from proposed_mp_logging_module import ApacheLogHandler
def handler(req)
req.content_type = 'text/plain'
log = logging.getLogger('request')
hdlr = ApacheLogHandler(req)
log.addHandler(hdlr)
log.setLevel(logging.INFO)
msg = 'Its all good'
log.info('%s' % msg)
req.write('check the logs for "%s"' % msg)
apache.OK
All fine and dandy. But isn't logger a singleton? So each time a request
is processed we'll be adding a reference to the request object, which
will never get garbage collected and result in a memory leak.
Furthermore, you can't depend on the request object being valid once
the request processing has completed. At some point request_tp_clear (in
requestobject.c) will get called and request->server will be set to
NULL. (At least I think this is correct). My gut tells me you'll get
some random seg faults.
Also, is there not an assumption that the logger instance is in effect
global? So let's say you change the level in one request such as
log.setLevel(logging.CRITICAL). In mpm-prefork or mpm-worker models
changing the log level will not propagate to the other child processes.
I expect most users will find this confusing.
As I said before I don't think this is as trivial to implement as it
might seem at first blush.
Regards.
Jim
