Config files for CGI::Application under mod_perl

Posted on 2004-08-02
Medium Priority
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
  • 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 2000 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:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/

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.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.


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

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

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…
Introduction Knockoutjs (Knockout) is a JavaScript framework (Model View ViewModel or MVVM framework).   The main ideology behind Knockout is to control from JavaScript how a page looks whilst creating an engaging user experience in the least …
The viewer will the learn the benefit of plain text editors and code an HTML5 based template for use in further tutorials.
The viewer will learn how to create a basic form using some HTML5 and PHP for later processing. Set up your basic HTML file. Open your form tag and set the method and action attributes.: (CODE) Set up your first few inputs one for the name and …
Suggested Courses

579 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