Suppose two versions of Apache::Status are being
hacked on the same server. In this configuration:
Apache::PerlVINC is loaded and then two different
locations are specified for the same handler
Apache::Status, whose development version resides
in /home/httpd/dev/lib and production version in
If a request for /status/perl is issued (the
latter configuration section), the fixup handler will internally do:
unshift @INC, "/home/httpd/prod/lib";
which will load the production version of the module, which will in
turn be used to process the request.
If on the other hand the request is for
/status-dev/perl (the former configuration
section), a different path (/home/httpd/dev/lib)
will be prepended to @INC:
unshift @INC, "/home/httpd/dev/lib";
It's important to be aware that a changed
@INC is effective only inside the
<Location> block or a similar configuration
directive. Apache::PerlVINCsubclasses the
PerlRequire directive, marking the file to be
reloaded by the fixup handler, using the value of
PerlINC for @INC.
That's local to the fixup handler, so you
won't actually see @INC changed
in your script.
Additionally, modules with different versions can be unloaded at the
end of the request, using the PerlCleanupHandler:
Also note that PerlVersion affects things
differently depending on where it is placed. If it is placed inside a
<Location> or a similar block section, the
files will be reloaded only on requests to that location. If it is
placed in a server section, all requests to the server or virtual
hosts will have these files reloaded.
As you can guess, this module slows down the response time because it
reloads some modules on a per-request basis. Hence, this module
should be used only in a development environment, not in production.
Available from CPAN. See the module manpage for more information.