simeon2000 has asked for the wisdom of the Perl Monks concerning the following question:

Brethren, I have read the mod_perl documentation as best I can, and I am still having some problems. I have the following module that is supposed to simply export a few variables to the web application:

package ISLog::Config; use warnings; use strict; BEGIN { use Exporter(); use vars qw( @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS ); @ISA = qw( Exporter ); @EXPORT = qw(); @EXPORT_OK = qw( $dbh $cgi $tt $cgv ); %EXPORT_TAGS = ( objects => [ qw( $dbh $cgi $tt ) ], ); } use Apache::Reload; use CGI(); use DBI; use Template; use vars qw( $dbh $cgi $tt $cgv ); $tt = new Template( INCLUDE_PATH => '/var/www/template/islog' ); $dbh = DBI->connect( 'dbi:mysql:host=xxx;database=xxx', 'xxx', 'xxx' ) or die DBI->errstr(); $cgi = new CGI(); $cgv = $cgi->Vars(); 1;
So that now in my other programs I can simply:

use ISLog::Config qw/ :objects $cgv /;
And Ta-daaaaa! I've got shared variables. Right? However, I've hit a snag. The database handler and CGI objects copy over fine 98% of the time, but the $cgv (which holds the $cgi->Vars() hashref) copies over empty on form submission scripts over 80% of the time. Every now and then it works, but mostly it doesn't. I've tried httpd -X and quite a few other things, but it just doesn't seem to work.

I recently tried adding the following two lines to the Config module:

print $cgi->header(); print "$_" for keys %$cgv;
at the bottom of the Config module to debug, and then almost magically, the $cgv hash was then populated in the calling script @_@. I'm going nuts here. Is there a bug in CGI under mod_perl? Am I just doing it stupid? Should I just give up this crazy import stuff? Any documentation, ideas, or LARTs would be appreciated. BTW this is latest && greatest mod_perl/apache.

--
perl -e "print qq/just another perl hacker who doesn't grok japh\n/"
simeon2000|http://holdren.net/

Replies are listed 'Best First'.
Re: mod_perl & Exporter
by Zaxo (Archbishop) on Aug 30, 2002 at 15:01 UTC

    Avoid making instance variables global in mod_perl. They get stepped on mid-session and they hang around after you're done with them.

    After Compline,
    Zaxo

Re: mod_perl & Exporter
by perrin (Chancellor) on Aug 30, 2002 at 15:38 UTC
    This is an okay way to share config data, but this is not config data. You shouldn't share objects in this way.

    To start with, you can't share DBI handles across a fork, i.e. you can't open a $dbh in startup.pl, httpd.conf, or any module used by a module called from one of those. Just use Apache::DBI.

    Next, CGI is a really bizarre module that does lots of awful things with global variables. As a result, it is full of hacks to make it work under mod_perl. If you can, I suggest getting rid of it and using Apache::Request or CGI_Lite. It looks to me like you are not creating a new CGI object on every request here, which will definitely screw things up.

    Finally, I wouldn't call these variables "shared". They are globals, and you are just using Exporter to shorten the namespace used for accessing them. You could skip all the Exporter stuff and just say $ISLog::Config::tt instead. And bear in mind that each apache child has a unique set of these variables, so any updates you make to them are not reflected in other apache children.

Re: mod_perl & Exporter
by simeon2000 (Monk) on Aug 30, 2002 at 14:46 UTC
    Forgot to mention, that even more hair-pullingly frustrating is the fact that $cgv is sometimes populated with parameters from previously requested forms.