Re: Setting PerlRequire in a Perl section
Actually, yes, I had. PerlVINC is not really what I needed, the goal was not to reload %INC per VirtualHost, the need was to have a single PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC would work). Ordinary this would have been done with something like 'use lib $FindBin::Bin/lib/, but since that doesn't work under mod_perl I was toying with using Perl sections. It sounds like maybe you were not understanding that in the mod_perl 1.x series there is only 1 Perl interpreter shared between all VirtualHosts (they are virtual, after all). That means there can only be one @INC for all VirtualHosts as well. Things like PerlVINC cheat by messing with @INC on each request. - Perrin
RE: Setting PerlRequire in a Perl section
I understood the limitation of the single interpreter, the problem again was to append to @INC per VirtualHost. For example, Application A: running on server 1 has its lib directory at /data/appA/lib/. Its lib packages are in namespace AppA:: (to prevent overlap in the single Perl interpreter). Application B: running on server 1 has its lib directory at /opt/appB/server/lib. Its lib packages are in namespace AppB::. The same applications when deployed on server 2, might or might not have the same absolute path to their lib directory. So, for example AppA's lib on server2 might live at /data4/servers/AppA/lib. The historical reason for the differences in path aren't important, just assume I can't fix them :-). Since all app's are segregated into namespaces for their packages, a single interpreter is OK, there is no overlap (we made that change specifically to support mod_perl). The goal was to be able to checkout the application source from our CVS repository, Include its app.httpd.conf from the main httpd.conf, and be ready to go, with the absolute path for each application's lib directory appended to @INC for StatINC to work. Obviously in order for that to work each App's startup.pl would need to be able to determine its path as it is PerlRequire'd, so it can build the needed path to the lib directory. Wihtout FindBin this doesn't work under mod_perl. Perl sections appeared to be capable of doing it (since the app.httpd.conf was located in the source tree of the app we could use $0 to find the path to app.httpd.conf) but attempting to do too much in a Perl section seemed to constantly cause breaks (I eventually gave up). As I mentioned previously we switched to absolute paths in the per-application startup.pl file. Its a pain to maintain a per-server times per-application list of lib paths, but that fixes us until I get to see what mod_perl 2.0 has in store for me :-) Thanks again for all the responses, Alex -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:06 AM To: Alex Harper; Stas Bekman Cc: [EMAIL PROTECTED] Subject: Re: Setting PerlRequire in a Perl section Actually, yes, I had. PerlVINC is not really what I needed, the goal was not to reload %INC per VirtualHost, the need was to have a single PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC would work). Ordinary this would have been done with something like 'use lib $FindBin::Bin/lib/, but since that doesn't work under mod_perl I was toying with using Perl sections. It sounds like maybe you were not understanding that in the mod_perl 1.x series there is only 1 Perl interpreter shared between all VirtualHosts (they are virtual, after all). That means there can only be one @INC for all VirtualHosts as well. Things like PerlVINC cheat by messing with @INC on each request. - Perrin
Re: Setting PerlRequire in a Perl section
I understood the limitation of the single interpreter, the problem again was to append to @INC per VirtualHost. It's confusing when you say that, since there's only one @INC for everything. I'm interpreting this as meaning that you have a bunch of applications with different install directories and you want them all to go in the global @INC. The goal was to be able to checkout the application source from our CVS repository, Include its app.httpd.conf from the main httpd.conf, and be ready to go, with the absolute path for each application's lib directory appended to @INC for StatINC to work. How do you avoid hard-coding the paths to app.httpd.conf then? If you're already hard-coding that path on each server, you should be able to just make everything else relative to that. Is that what you were trying to do with your original post? That code would work fine if you change $PerlRequire to a straight 'require'. They do the same thing. Perl my $dirroot = $0; $dirroot = s/\.htaccess$//; require ($dirroot . 'modperlstartup.pl'); /Perl As I mentioned previously we switched to absolute paths in the per-application startup.pl file. Its a pain to maintain a per-server times per-application list of lib paths, but that fixes us until I get to see what mod_perl 2.0 has in store for me :-) Well, what Stas was talking about with mod_perl 2 was just having different Perl interpreters (with different @INCs) per VirtualHost, which actually doesn't sound like it has much to do with your problem. I still don't understand what problem you're trying to solve well enough to give good advice, but configuration management issues are commonly handled through an installation process that sets local paths. The last time I had to do that for a mod_perl app, we used Template Toolkit to generate our httpd.conf and startup.pl with local paths during the install. For simpler localization, you could just use a couple of substitutions, or you could try playing with MakeMaker. - Perrin
RE: Setting PerlRequire in a Perl section
I understood the limitation of the single interpreter, the problem again was to append to @INC per VirtualHost. It's confusing when you say that, since there's only one @INC for everything. I'm interpreting this as meaning that you have a bunch of applications with different install directories and you want them all to go in the global @INC. Sorry for the confusion. Your interpretation is correct. I wish to add several different paths to the common global @INC, one per application. How do you avoid hard-coding the paths to app.httpd.conf then? If you're already hard-coding that path on each server, you should be able to just make everything else relative to that. Is that what you were trying to do with your original post? That code would work fine if you change $PerlRequire to a straight 'require'. They do the same thing. Exactly, the only abs path we would like is the per-server master httpd.conf. The difference (or lack thereof) between PerlRequire and require in a Perl section wa lost on me. Thanks for the tip. Well, what Stas was talking about with mod_perl 2 was just having different Perl interpreters (with different @INCs) per VirtualHost, which actually doesn't sound like it has much to do with your problem. Not directly, no it wouldn't, although I actually would like to see this for other issues we had earlier (which we solved by moving all our packages into unique namespaces). I'll look into the other configuration solution you mentioned, although I expect they provide more than we really need for these applications. Thanks, Alex
Re: Setting PerlRequire in a Perl section
Alex Harper wrote: Hi, I'm trying to configure a PerlRequire directive in a Perl section of an .htaccess file. This is done so that I can have several directories (one per VirtualHost) load a different PerlRequire startup without resorting to absolute paths for the startup for each VirtualHost. Since FindBin doesn't work for much of anything under mod_perl the solution I'm trying in the .htaccess file is roughly: Perl my $dirroot = $0; $dirroot = s/\.htaccess$//; $PerlRequire = $dirroot . modperlstartup.pl; /Perl However this results in the server spinning off into never-never land as soon as the first mod_perl enabled CGI from the directory is loaded. If I load the PerlRequire outside the perl section (using the exact absolute path generated by the code above) everything is fine. Does anyone have any suggestions? Is it safe to add a PerlRequire in a Perl section? I see no mention of it anywhere, but then again I also see no examples that do it. More generally is there a better/correct way to do this? All the examples I can find in Stas Bekman's (excellent BTW) guide always use absolute paths for the startup files and any use lib pragmas. What I really need is a way to modify the path to the startup and the path to lib on the basis of the VirtualHost and I'd like to avoid hardcoding the paths. mod_perl 2.0 has solved these problems already, but it's not in production yet :) Have you read this one? http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_on You probably need to use Apache::PerlVINC, but it's not very efficient. -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Setting PerlRequire in a Perl section
mod_perl 2.0 has solved these problems already, but it's not in production yet :) Well that give me something to look forward to :-) Have you read this one? http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_o n You probably need to use Apache::PerlVINC, but it's not very efficient. Actually, yes, I had. PerlVINC is not really what I needed, the goal was not to reload %INC per VirtualHost, the need was to have a single PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC would work). Ordinary this would have been done with something like 'use lib $FindBin::Bin/lib/, but since that doesn't work under mod_perl I was toying with using Perl sections. For the record the problem was the line: $PerlRequire = $somepath; Which needed to be: push @PerlRequire, $somepath; Although why the previous version set the server spinning off I never could figure out. It happened even with Apache::Server::StrictPerlSections on. In any case I've settled on absolute paths just like the examples. This increases the maintenance costs with multiple startup scripts, but solves the problem in the most obvious way. Maybe this will be easier in mod_perl 2.0? Thanks for the help, Alex
Re: Setting PerlRequire in a Perl section
Alex Harper wrote: mod_perl 2.0 has solved these problems already, but it's not in production yet :) Well that give me something to look forward to :-) Have you read this one? http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_o n You probably need to use Apache::PerlVINC, but it's not very efficient. Actually, yes, I had. PerlVINC is not really what I needed, the goal was not to reload %INC per VirtualHost, the need was to have a single PerlRequire set up @INC properly per VirtualHost (so Apache::StatINC would work). Ordinary this would have been done with something like 'use lib $FindBin::Bin/lib/, but since that doesn't work under mod_perl I was toying with using Perl sections. For the record the problem was the line: $PerlRequire = $somepath; Which needed to be: push @PerlRequire, $somepath; This won't work as you have seen already. If you don't mind reloading the libs at run time, you can always call do() on FindBin which will force the reload of all its internals. Although why the previous version set the server spinning off I never could figure out. It happened even with Apache::Server::StrictPerlSections on. In any case I've settled on absolute paths just like the examples. This increases the maintenance costs with multiple startup scripts, but solves the problem in the most obvious way. Maybe this will be easier in mod_perl 2.0? All I can tell you is that it works already :) and it's very easy. Now let's see how soon httpd 2.0 gets released and how soon we get mod_perl 2.0 out (which of course depends on Apache's release) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Setting PerlRequire in a Perl section
Hi, I'm trying to configure a PerlRequire directive in a Perl section of an .htaccess file. This is done so that I can have several directories (one per VirtualHost) load a different PerlRequire startup without resorting to absolute paths for the startup for each VirtualHost. Since FindBin doesn't work for much of anything under mod_perl the solution I'm trying in the .htaccess file is roughly: Perl my $dirroot = $0; $dirroot = s/\.htaccess$//; $PerlRequire = $dirroot . modperlstartup.pl; /Perl However this results in the server spinning off into never-never land as soon as the first mod_perl enabled CGI from the directory is loaded. If I load the PerlRequire outside the perl section (using the exact absolute path generated by the code above) everything is fine. Does anyone have any suggestions? Is it safe to add a PerlRequire in a Perl section? I see no mention of it anywhere, but then again I also see no examples that do it. More generally is there a better/correct way to do this? All the examples I can find in Stas Bekman's (excellent BTW) guide always use absolute paths for the startup files and any use lib pragmas. What I really need is a way to modify the path to the startup and the path to lib on the basis of the VirtualHost and I'd like to avoid hardcoding the paths. Thanks, Alex -- Alex HarperBroadJump, Inc. [EMAIL PROTECTED]Configuration Manager
