On Tue, 31 Jul 2001, Philip Mak wrote:
On Tue, 31 Jul 2001, Kyle Oppenheim wrote:
Apache::Reload works by performing a stat on every file in %INC and calling
require for all the files that changed. It's quite possible that some of
the files in %INC are using relative paths (often '.' is in @INC). So, Perl
was able to load the file originally because the initial 'use' or 'require'
was after Apache changed to your directory. However, when Apache::Reload
goes to look for the file, it can't find it because the current directory is
different (most likely the ServerRoot).
I've ran into this problem with Apache::Reload a couple of times myself.
Isn't there a way that Apache::Reload can be made to work transparently
(in the spirit of making programs Do The Right Thing (tm))? Perhaps by
overloading the use and require functions to convert pathnames to be
fully qualified before inserting them in %INC?
This is a good idea, though you cannot do that unless you are running
under 5.6 or some earlier Perl which supports the notion of GLOBAL::CORE::
namespace (which can be a bad thing to do anyway). Or write some XS code
:)
Extending your @INC is the simplest solution. The docs should be updated
and you will be all set.
(I think this would also help with same-named mod_perl scripts from
different VirtualHosts in the same instance of Apache interfering with
each others' execution?)
Not really. You have 1:1 mapping in %INC. How exactly do you suggest it to
work?
It'll be all clean in mod_perl 2.0, where every vh will have its own pool
of interpreters if wanted, with a private copy of %INC.
_
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/
