Re^2: mod_perl and multiple installations of the same code

SiteConfig.pm is very simple. Here is an example:

package SiteConfig;

use strict;

use Exporter;

our $c;

@SiteConfig::ISA       = qw(Exporter);
@SiteConfig::EXPORT_OK = qw($c);

$c->{dbname}          = 'somedb';
$c->{dbserver}        = 'somehost';
$c->{dbuser}          = 'someuser';
$c->{dbpass}          = 'somepass';

$c->{site_name}       = 'Some Plain Text Name';

$c->{domain}          = 'some-domain.com';

#... and a bunch more ...
[download]

Then the other various modules say stuff like: use SiteConfig qw($c); So what would need to happen is that SiteConfig would have to export a "$c" that is appropriate for the current request (based on some way to determine which of four domains it's serving). That doesn't even seem possible (to export something different at run-time when it's loaded when mod_perl starts). I think we'd have to change the interface from Exporter to a function or method call (in every one of our modules). There is also one "quick access" method inside SiteConfig.pm that allows you to grab any value w/out importing $c:

sub param {
    return $c->{(shift)};
}
[download]

That one seems like it would be easy to modify to return the appropriate value, if only I knew some reliable way to determine from which domain the request was coming.

Comment on Re^2: mod_perl and multiple installations of the same code Select or Download Code

Replies are listed 'Best First'.
Re^3: mod_perl and multiple installations of the same code by nobull (Friar) on Mar 16, 2005 at 20:20 UTC
So what would need to happen is that SiteConfig would have to export a "$c" that is appropriate for the current request (based on some way to determine which of four domains it's serving). That doesn't even seem possible (to export something different at run-time when it's loaded when mod_perl starts). Tied variables allow you to have things that appear to be variables but are in fact subroutines. `package SiteConfig; use strict; use base 'Exporter'; tie our $c, 'SiteConfig'; our @EXPORT_OK = qw($c); sub FETCH {{ dbname => 'somedb', dbserver => 'somehost', dbuser => 'someuser', dbpass => 'somepass', site_name => 'Some Plain Text Name', domain => 'some-domain.com', #... and a bunch more ... }}` [download]	[reply] [d/l]
Re^4: mod_perl and multiple installations of the same code by saberworks (Curate) on Mar 17, 2005 at 18:10 UTC
This is great. I'm going to try a combination of this and the Apache::Request host checking mentioned above by cowboy. Thanks!	[reply]
Re^3: mod_perl and multiple installations of the same code by cowboy (Friar) on Mar 16, 2005 at 20:19 UTC
Running under mod_perl, you should be able to get an Apache::Request object easily, using something like this: `# $c = { 'foo.com' => { dbname => 'foo', dbuser => 'foo', }, 'bar.com' => { dbname => 'bar', dbuser => 'bar', } }; sub param { my $param = shift; # get a request instance my $r = Apache::Request->instance(); # get the hostname my $host = $r->hostname(); return $c->{$host}->{$param}; }` [download] This obviously doesn't take into account 'www.foo.com' and 'foo.com' if they're the same thing, but a little munging of $host before using it, should allow you to find the right one, or worst case, fall back to a default.	[reply] [d/l]