On Fri, Nov 07, 2003 at 05:57:25AM -0500, Jeff Trawick wrote: > Glenn wrote: > >Maybe out in left field, but could ErrorLog be moved from the core > >and into mod_log_config? Then, if mod_log_config is not present, > >or no ErrorLog directive is specified, then stderr can be used. > >Any special reason to keep it in the core? > > because it is a critical function? > > If it is able to format write to stderr if no module has taken over the > function, most of the existing support is required anyway. And if core > code does the work of formatting, then there is no use in an external > module to have to do that.
Not so. You said yourself that the code that handles piped logs is in two places, once in the core and once in mod_log_config, and this prevented you from committing a patch which only fixed a problem in one of those places. The point of my message was to suggest getting rid of the duplicated code and moving the ErrorLog directive to mod_log_config (or elsewhere). I am not suggesting moving all error logging out of the core since I agree that it is critical, just moving the interface to direct log output elsewhere (other than stderr). > Apache 2.0 did add an error log hook so that modules can grab error log > entries and log them however they want. So some mod_log_error (why clutter > up mod_log_config) could handle error log; we'd just need a way to turn off > the default error log. I haven't looked at the Apache2 error logging code carefully -- I'm still trying to get a 4 line patch applied to Apache 1.3 error logging code. I was thinking along the lines of mod_log_config exporting a function to handle piped logs. If it exists, the core would send the formatted error message to that filter instead of to stderr. Of course, this function could even be abstracted from mod_log_config into a "mod_log_gw" log gateway which would take a formatted string and send it to a file, a pipe, redirected >> output, a database, etc. Main point: duplicated code == BAD. Cheers, Glenn
