httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: help with apache configuration "logic"...
Date Mon, 03 Jun 2002 16:52:48 GMT
> > > 1/ as 'PRE' is a latin prefix which means before, would it be
> > for
> > >    the sanity of the developpers to either:
> > >    a/ call it *before* the configuration is read.
> > >    b/ or rename it 'post_config';-)
> > >       then the 'post_config' can be renamed 'post_post_config';-)
> >
> > No, neither is possible.  The pre refers to when we process the
> > not when it is read.
> Argh. So I need pre/post_read_file hook maybe;-)

You don't need it in 2.0.  The new config system was specifically
designed to allow the type of thing that mod_macro does.

> > > 2/ if the pre_config is to be run anyway after the configuration
> > is  read, could you suggest another hook I could use ? I can't see
> > any...
> > >    and the developper documentation is rather scarse and not up to
> > date.
> > >
> > > 3/ or explain what I missed in the source code to understand the
> > >    behind all that.
> >
> > The easiest way to solve the problem you are looking at, is to mark
> > Macro directives as EXEC_ON_READ,
> I already needed that so as to be able to locate error messages, as
> cmd->config_file field is not defined otherwise, and I have to deal
> it. The problem is that I need an initialization *before* lines are
> submitted to my commands, and this does not solve this issue at all.

The register_hooks phase is run as soon as the module is loaded, so you
can use that phase for your initialization.

> > that will get the macros loaded while we read the config file.
Then, in
> > pre_config, walk the tree looking for the macro names, and replace
> > with the definitions that you read in earlier.
> It seems to me not to work, as you can have a macro definition within
> macro, which might be defined after macro expansion.

That doesn't matter.  I was actually wrong earlier, you don't want
EXEC_ON_READ at all.  The whole thing can be done without it.  Just
define a pre_config function.  That function will walk the tree and find
all macro definitions.  Then, the second pass (not optimal, but easiest
to explain) will expand all macros.  Any macros inside a macro will be
automatically expanded if coded properly.

> Also, I have a problem understanding what you mean by 'walk the tree'.
> macro processing simply performs a macro expansion at the textual
> which is parsed after expansion by modifying on the fly the
> structure with my own stuff...

The Apache 2.0 config system has been changed, it no longer relies on
the text file.  Instead, the server reads the file into a tree that
resides in memory.  The server walks the tree to determine the
configuration.  By manipulating the tree before the server walks it,
your module can impact the configuration.  This is what the pre_config
phase is for.

> I can't see anyway a parse-tree for apache configuration file, given
> lexical structure... Is there such a thing?

Take a look at the worker.c file, worker_pre_config function for an
example of how to modify the configuration tree.

> Thus I think that it would be great if I had a pre/post read hook,
> really?!
> How can I get one? Or should I investigate the 'tree' stuff and try to
> cast my stuff into that?

You don't need a pre/post read hook, and I am very much against adding
one.  Please look at the configuration tree to solve your problem.


View raw message