On Sun, 31 Mar 2002 12:43:45 -0800 (PST) [EMAIL PROTECTED] wrote:
> Hi! I had a question regarding where I should be placing global
> configuration options in mod_perl. Here's the qweekie scenario:
>
> I want to load a configuration file of various options (such as db
> arguments, system directories, db connections, etc.) into a hash or
> perl object global to Apache so that my mod_perl handlers have access
> to this variable/object, kinda like the %ENV variable except that I
> wish to keep these pieces of information separate from the %ENV
> variable. Initially, I thought about loading this configuration
> information in a startup script and using the PerlRequire directive to
> load this script. However, since doing this code will run under root
> privileges, would it be a good idea to place this type of information
> in this file? Also, I read about issues of database handlers becoming
> unstable across forks. So should I place this initialization
> information into a perl child init handler?
>
> Second if I want to utilize virtual hosting on a single machine with
> mod_perl loaded into certain hosts, what would this situation do in
> terms of allowing those hosts to access these variables? What should
> I do if I want a kind of separate configuration environment per
> virtual host in mod_perl and to load that configuration environment up
> before a request to improve performance?
We use PerlSetVar's for this where I work. It goes something like this:
<Location /foo>
SetHandler perl-script
PerlHandler MyHandler::Foo
PerlSetVar DatabaseName foo
PerlSetVar DatabaseUser foouser
PerlSetVar DatabasePass foo$secret
</Location>
In the code we grab these variables like so:
sub handler {
my $r = shift;
my %vars = ();
$vars{dbname} = $r->dir_config('DatabaseName');
$vars{dbuser} = $r->dir_config('DatabaseUser');
$vars{dbpass} = $r->dir_config('DatabasePass');
}
We actually have 10 or so common configuration parameters on most of
of our modules so we move all of our $r->dir_configs into an init()
subroutine.
Anyway... this might be one way to attack your problem, as you can
then use different parameters on each virtual host.
---------------------------------
Frank Wiles <[EMAIL PROTECTED]>
http://frank.wiles.org
---------------------------------
