Pratik wrote:
The sample configuration file which I assume to be pretty common, can be something like below :
============================== PerlPassEnv APP_HOME <Perl> @Include = "$ENV{APP_HOME}/conf/common.conf"; </Perl>
PerlPassEnv HOME PerlPassEnv PORT <Perl> $ServerRoot = $ENV{HOME} . "/web"; $DocumentRoot = $ENV{HOME} . "/web/public" ; $Listen = $ENV{PORT}; </Perl>
Thanks for the example, Pratik. Now it's more clear to me.
I propose the following "simple" solution:
1) Keep %ENV intact at the server startup, so anything set in the shell is seen from perl
2) PerlPassEnv and PerlSetEnv aren't run yet but postponed to until after post_config.
3) just before starting workers, detach %ENV from environ, cleaning it up completely. now run PerlPassEnv and PerlSetEnv from (2)
That way we don't have to deal with the painful timing of PerlPassEnv and PerlSetEnv. We simply document that those have an affect *only* post-post_config phase, i.e. starting from child_init phase. If someone wants to modify %ENV as it's seen from shell, they can just do that with <Perl> sections.
Opinions?
So Pratiks example will become just:
<Perl>
@Include = "$ENV{APP_HOME}/conf/common.conf";
</Perl><Perl>
$ServerRoot = $ENV{HOME} . "/web";
$DocumentRoot = $ENV{HOME} . "/web/public" ;
$Listen = $ENV{PORT};
</Perl>assuming that you don't need any of those ENV vars after config phase.
In fact this makes %ENV even smaller.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
