Stas Bekman wrote:
> 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).
>
That explains the library files not reloading - Thanks!
>
> 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.
I didn't realize that using the library wrapper was a cheap workaround
to the nested subroutine problem. The effects of the nested subroutine
problem is my biggest concern with writing code for mod_perl. What
I liked about the lib.pl trick is that it completely eliminates this problem.
I won't lose sleep wondering if somehow the code went into production
with a nested subroutine. I realize that there are other ways to eliminate
the nested subroutine problem, but what are the preferred techniques
used by mod_perl developers? Check the error_log file for problems
and fix as needed?
>
> Was this explanation clear enough? We need to add it to the
> Apache::Reload manpage to avoid this kind of questions in the future.
>
Makes sense.
>
> 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
--
Ted Prah
NetCasters, Inc.
[EMAIL PROTECTED]
