On Saturday 01 May 2010, Jeff Trawick wrote: > I would like to see some buy-in for the API changes. I don't have > any other concerns about committing. (Logging is such a part of > main-line that many more people will see the changes in action > while working on other issues, giving ample opportunity for > necessary improvements/adjustments before 2.4 GA.)
Sure. I agree that there should be enough time to fix the details after this has gone into trunk. > > I think, instead of touching every file, it would be possible to > > have a field in the module struct listing the filenames belonging > > to a module. With some clever coding it should even be possible > > to do this without having to do string compares during the > > logging. But I don't think that this would be a better solution. > > For example, there can be duplicate filenames (we already have > > two util.c files). After thinking a bit more about this idea, I don't think that it would work after all. It would require having the name of the source file that includes some header file available in the header file. But there is only __FILE__ and that expands to the name of the header file when used in a header. I now believe we really have to touch every source file to somehow declare which module it belongs to. And if we have to do that in any case, defining AP_MODULE_VAR seems to be ok. > For selection by module, does the facility need to be more granular > than simply using the canonical source file name -- the name of the > file that declares the module struct? I am not sure what you mean. Somehow it must be clear what module is to be used for logging. Or do you mean that the user may want to have finer log config granularity than by module, e.g. for mod_ssl or for the core module? That may be a nice extension in the future but for now configuring the log level by module is enough. Cheers, Stefan
