RE: help with apache configuration "logic"...

[Ryan Bloom <rb...@covalent.net>]

> I'm in the process of porting to apache 2 a module I developped for
> apache 1.3. The 'mod_macro' module add macro definition capabilities
> to apache configuration files. Macros are expanded on the fly and
parsed.
> 
> With apache 1.3, I needed an initialization phase each time a new
> configuration cycle is started, as there are two analyses of the
> configuration file each time apache is launched. The hack I found was
to
> notice that the temporary pool has changed to re-initialized my
internal
> data structures which holds the description of macros... quite poor.
> 
> Now with apache 2, I digged out in the source code a 'pre_config' and
> 'post_config' hook that look just fine, so I was planing to use that
> instead of the previous hack. However :
> 
> 1/ the apache configuration is still read twice.
>    well, why not if it pleases you.
> 
> 2/ the pre_config hook is run *AFTER* the configuration file
>    is read. Indeed, you can see that in main.c where
>    ap_run_pre_config() is called after ap_read_config()

Yes, but it is read before the file is actually processed.  There is
VERY little done when the configuration file is read, other than to
create a configuration tree.  Essentially, we load all modules, and
determine the validity of IfDefine and IfModule directives.  All other
directives are evaluated later.

> Thus here are my questions:
> 
> 1/ as 'PRE' is a latin prefix which means before, would it be possible
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 config,
not when it is read.

> 2/ if the pre_config is to be run anyway after the configuration file
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 logic
>    behind all that.

The easiest way to solve the problem you are looking at, is to mark the
Macro directives as EXEC_ON_READ, 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 them with the definitions that you read in
earlier.

Ryan

RE: help with apache configuration "logic"...

[Fabien COELHO <co...@cri.ensmp.fr>]

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

Ok. I'm going to investigate that. It seems that I'll need to restructure
the whole stuff for apache 2 instead of the minimum time port I hopped for
initially.


Fabien.

RE: help with apache configuration "logic"...

[Ryan Bloom <rb...@covalent.net>]

> > > 1/ as 'PRE' is a latin prefix which means before, would it be
possible
> > 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
config,
> > 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
file
> > 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
logic
> > >    behind all that.
> >
> > The easiest way to solve the problem you are looking at, is to mark
the
> > Macro directives as EXEC_ON_READ,
> 
> I already needed that so as to be able to locate error messages, as
the
> cmd->config_file field is not defined otherwise, and I have to deal
with
> 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
them
> > with the definitions that you read in earlier.
> 
> It seems to me not to work, as you can have a macro definition within
a
> 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'.
The
> macro processing simply performs a macro expansion at the textual
level,
> which is parsed after expansion by modifying on the fly the
config_file
> 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
its
> 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.

Ryan

RE: help with apache configuration "logic"...

[Fabien COELHO <co...@cri.ensmp.fr>]

Hello Ryan,

thanks for your reply.

> > 1/ as 'PRE' is a latin prefix which means before, would it be possible
> 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 config,
> not when it is read.

Argh. So I need pre/post_read_file hook maybe;-)

> > 2/ if the pre_config is to be run anyway after the configuration file
> 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 logic
> >    behind all that.
>
> The easiest way to solve the problem you are looking at, is to mark the
> Macro directives as EXEC_ON_READ,

I already needed that so as to be able to locate error messages, as the
cmd->config_file field is not defined otherwise, and I have to deal with
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.

> 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 them
> with the definitions that you read in earlier.

It seems to me not to work, as you can have a macro definition within a
macro, which might be defined after macro expansion.

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

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

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?

Thanks again for your help,

-- 
Fabien