Bug #29668 for CGI-Application-Plugin-DBIProfile: Unable to set ENV vars via PerlSetVar

Sat Sep 29 14:04:54 2007 GTERMARS [...] cpan.org - Ticket created

Subject:

Unable to set ENV vars via PerlSetVar

Perhaps its just how I've got my own environment set up, but I've been unable to get this module to work if I set the ENV vars using PerlSetVar in my httpd.conf file. OTOH, if I use a BEGIN block to set them up in either: a) startup.pl, or b) my own CGI::App base class then things work fine. FYI, I'm also using CAP::DevPopup, whose documentation shows that CAP_DEVPOPUP_EXEC needs to be enabled before the module is loaded (e.g. via BEGIN block). If I used PerlSetVar things didn't work, but if I enabled the ENV vars in the same place that I've got my CAP::DevPopup stuff enabled, it worked like a charm.

Sat Sep 29 17:56:22 2007 unrtstRMSPAM [...] cpan.org - Correspondence added

Resolved in 0.05

Sat Sep 29 17:56:24 2007 The RT System itself - Status changed from 'new' to 'open'

Sat Sep 29 17:56:24 2007 unrtstRMSPAM [...] cpan.org - Status changed from 'open' to 'resolved'

Sun Sep 30 12:19:14 2007 unrtstRMSPAM [...] cpan.org - Correspondence added

I'm not sure why that is. I've tested under apache 1.3, with and without mod_perl, and using SetVar + PerlSetVar worked for me. For PerlSetVar to work, the pages being served will need to be served by mod_perl, and those will need set prior to the modules being included. So, for example, if you have a startup.pl that loads common modules, that will need included after the PerlSetVar. If that's the case, the following can be used to keep the config in your apache config (if you want): <Perl> $ENV{CAP_DBIPROFILE_EXEC} = 1; </Perl> SetEnv CAP_DBIPROFILE_EXEC 1 PerlSetEnv CAP_DBIPROFILE_EXEC 1 PerlRequire /path/to/your/startup.pl The above is a little overkill, but it should work regardless. The <Perl> blocks should get exec'd prior to the PerlRequire. Setting the env vars in a BEGIN{} block in your setup.pl or CAP module is fine too. I just prefer to keep debug flags outside my code, so I can use the same code across various webservers/vhosts, and enable things from the server level. TMTOWTDI On Sat Sep 29 14:04:54 2007, GTERMARS wrote: Show quoted text

> Perhaps its just how I've got my own environment set up, but I've been > unable to get this module to work if I set the ENV vars using > PerlSetVar in my httpd.conf file. > > OTOH, if I use a BEGIN block to set them up in either: > > a) startup.pl, or > > b) my own CGI::App base class > > then things work fine. > > FYI, I'm also using CAP::DevPopup, whose documentation shows that > CAP_DEVPOPUP_EXEC needs to be enabled before the module is loaded > (e.g. via BEGIN block). If I used PerlSetVar things didn't work, but > if I enabled the ENV vars in the same place that I've got my > CAP::DevPopup stuff enabled, it worked like a charm.

Sun Sep 30 12:19:16 2007 The RT System itself - Status changed from 'resolved' to 'open'

Sun Sep 30 15:48:02 2007 GTERMARS [...] cpan.org - Correspondence added

From:

GTERMARS [...] cpan.org

On Sun Sep 30 12:19:14 2007, UNRTST wrote: Show quoted text

> I'm not sure why that is. I've tested under apache 1.3, with and > without mod_perl, and using SetVar + PerlSetVar worked for me.

Hmm... maybe that has to do with it; I'm using Apache-2.2.2 w/MP2. Show quoted text

> For PerlSetVar to work, the pages being served will need to be > served by mod_perl, and those will need set prior to the modules > being included. So, for example, if you have a startup.pl that > loads common modules, that will need included after the > PerlSetVar. If that's the case, the following can be used to keep > the config in your apache config (if you want):

Yup, aware of that; the ENV vars all have to get set -before- the modules load, as they en/disable themselves at load time via "import()" (similarly to how CAP::DevPopup en/disables itself). Show quoted text

> Setting the env vars in a BEGIN{} block in your setup.pl or CAP > module is fine too. I just prefer to keep debug flags outside my > code, so I can use the same code across various webservers/vhosts, > and enable things from the server level. TMTOWTDI

I've been doing my CAP::DevPopup stuff iny "startup.pl" file, inside of a block that checks to see if I'm running on a test/devel box or whether its the production environment. If its a test/devel box then I enable CAP::DevPopup (and now this module too), otherwise they're disabled. Has worked well for me as I can just deploy the same codebase out to multiple boxes and it "does the right thing" depending on what machine its installed on.