Apache Perl Modules (Practical mod

Many third-party modules have been written to extend mod_perl's core functionality. They may be distributed with the mod_perl source code, or they may be available from CPAN. In this chapter we will attempt to group these modules based on their functionality. Some modules will be discussed in depth, but others will be touched on only briefly.

Since most of these modules are continually evolving, the moment this book is published much of the information in it will be out of date. For this reason, you should refer to the modules' manpages when you start using them; that's where you will find the most up-to-date documentation.

B.1. Development-Stage Modules

The following modules are mainly useful during the code-development cycle. Some of them can also be useful in the production environment.

B.1.1. Apache::Reload—Automatically Reload Changed Modules

Apache::Reload is used to make specific modules reload themselves when they have changed. It's also very useful for mod_perl module development.

Covered in Chapter 6.

Available from CPAN. See the module manpage for more information.

B.1.2. Apache::PerlVINC—Allow Module Versioning in <Location> and <VirtualHost> blocks

This module makes it possible to have different @INC values for different <VirtualHost>s, <Location>s, and equivalent configuration blocks.

Suppose two versions of Apache::Status are being hacked on the same server. In this configuration:

PerlModule Apache::PerlVINC

<Location /status-dev/perl>
    SetHandler       perl-script
    PerlHandler      Apache::Status

    PerlINC          /home/httpd/dev/lib
    PerlFixupHandler Apache::PerlVINC
    PerlVersion      Apache/Status.pm
</Location>

<Location /status/perl>
    SetHandler       perl-script
    PerlHandler      Apache::Status

    PerlINC          /home/httpd/prod/lib
    PerlFixupHandler Apache::PerlVINC
    PerlVersion      Apache/Status.pm
</Location>

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 /home/httpd/prod/lib.

If a request for /status/perl is issued (the latter configuration section), the fixup handler will internally do:

delete $INC{"Apache/Status.pm"};
unshift @INC, "/home/httpd/prod/lib";
require Apache::Status;

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:

delete $INC{"Apache/Status.pm"};
unshift @INC, "/home/httpd/dev/lib";
require Apache::Status;

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:

<Location /status/perl>
    SetHandler         perl-script
    PerlHandler        Apache::Status

    PerlINC            /home/httpd/prod/lib
    PerlFixupHandler   Apache::PerlVINC
    PerlCleanupHandler Apache::PerlVINC
    PerlVersion        Apache/Status.pm
</Location>

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.