Config files for CGI::Application under mod_perl

Posted on 2004-08-02
Last Modified: 2013-11-18
I have a CGI::Application module running on Apache with mod_perl.  The CGI::Application module is stored centrally, with the instance scripts located on multiple sub-sites.  I want to be able to use different configuration files for the different instances.  My current version has been written to just work correctly on a single one of our sub-sites and runs by using another package to load the configuration file into memory and to provide the relevant subroutines to extract the data (there is a system of defaults for many of the configuration settings, so the package has the ability to decide whether information has been set locally).

Has anyone got any suggestions on how I might be able to alter it in order to be able to use the modules centrally, then defining which configuration file (located in the sub-site) to use in the instance script?

Question by:mrh30
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
LVL 18

Expert Comment

ID: 11695465
Hi mrh30,

You do know you can pass in parameters to the cgi-app constructor in your instance scripts, right?
I'd suggest you make your config module flexible enough that you can pass it a path where it can find the site-specific config file.
You'd pass this path on from the instance script to your cgi-app module, which passes it on to the config module.


Author Comment

ID: 11701187
Yeah, I knew that already (and was planning on doing something similar).

My problems with it were as follows:

1. When you do a 'use ModuleName' statement, how are you able to pass any parameters to the module you are using?

2. Won't mod_perl cause some problems with this - will it not load the module into memory with the setup defined the first time you loaded it and then never change it, even when you try and use it on a different site?

What I've now done is rewritten it so that the settings are a fully fledged object.  It's not quite as nice in the code as it means that I can't just export the methods that I want to use around my main program; I have to store the config object as a parameter of the CGI::Application and then get it out when I need it.

I believe this will be mod_perl safe, as each version of the application will instantiate a different version of the config module.
LVL 18

Accepted Solution

kandura earned 500 total points
ID: 11702446
1. I'm not aware of a way to pass parameters through the "use" statement;
2. Yes, if you use package variables for the config, then they will be set during compile time (i.e. the first time your 'use My::Config;' is called), and they will remain the same across your vhosts;

So yes, you need a way to make sure you get the correct config for each vhost. Using package variables will make them the same across vhosts, so you're forced to find a dynamic way. An object is IMHO the cleanest way to do it. It could be nice to make your config a plugin, similar to the query object, so you could say $self->config->param('some_value').
There was some discussion about plugins on the cgiapp mailing list recently, which may be interesting for you. I haven't implemented it myself yet, but I definitely plan to.

Web Archive:

Relevant links:

I just had another idea: cache the config values in a hash table. The hash could be a package global, available to all vhosts. You could then use the keys for the instance-specific configs, which you could pass in through your instance script. I don't know if it will be feasible to rewrite your current config module to such a setup though.
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 11702805
Thanks for this - useful stuff.

I guess we've pretty much arrived at the same conclusion.  Have some points...
LVL 20

Expert Comment

ID: 11705306
The use statement has a very constrained way to pass parameters into a module's 'import' method. It might be enough to establish some configuration variables.

Author Comment

ID: 11705361
I guess you perhaps could pull off some trick like that, but I doubt that it would work in this instance: wouldn't there be problems with mod_perl and this.  As far as I can tell we'd be effectively creating some global variables.
LVL 18

Expert Comment

ID: 11707552
Yes, I think so too, since you would need to store those parameters in package variables anyway. That has the risk of clobbering the values of another vhost.

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I have been pestered over the years to produce and distribute regular data extracts, and often the request have explicitly requested the data be emailed as an Excel attachement; specifically Excel, as it appears: CSV files confuse (no Red or Green h…
I found this questions asking how to do this in many different forums, so I will describe here how to implement a solution using PHP and AJAX. The logical flow for the problem should be: Write an event handler for the first drop down box to get …
The viewer will learn how to dynamically set the form action using jQuery.
Video by: Mark
This lesson goes over how to construct ordered and unordered lists and how to create hyperlinks.

710 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question