Ted Prah wrote: >>do you test only this script alone? What happens if you add the package >>declaration and then call it using the full name? e.g.: >> > > > Yes, this is the only script (and corresponding library file) that I use > for this test. When I use the package declaration and make the call > using the full name, the reloads work fine. > > The reason I am using the library file is to follow your recommendation > in the mod_perl guide where a script is split into two files to avoid > the nested subroutine problem. Out of curiosity I tested the sample > code (counter.pl and mylib.pl) and they too did not reload properly > when mylib.pl was modified. Does the reloading of a modification > of mylib.pl work for you? I would prefer to use the library file > approach as opposed to the package approach as a lot of our code > uses libraries that are not in packages, but will move to packages if > that is a necessity.
Well, that explains everything. When you require() a library without that doesn't declare a package for the first time from the registry script, all its global symbols (subs, vars, etc) get imported into the namespace of the caller, i.e. the registry script (APACHE::ROOT::...). When Apache::Reload require()s that library that doesn't declare a package, all the global symbols end up in the Apache::Reload namespace! So the library does get reloaded and you see the compile time errors if there are any, but the symbols don't get imported to the right namespace. So the old code is running. Moreover this leads to a pollution of the Apache::Reload namespace, which may cause to problems if you happen to overwrite some of its symbols (subs, vars, etc). I suppose if you want to use the cheap workaround, you have to s/require/do/. Remember that the guide suggests the lib.pl trick as a workaround, not a solution you go with during the normal development. Was this explanation clear enough? We need to add it to the Apache::Reload manpage to avoid this kind of questions in the future. Funny though, that it's the first time this problem has been reported. Which shows that most of the people don't use workarounds when they do real developments :) __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
