On Tue, 2003-03-11 at 19:46, Stas Bekman wrote:
Stas Bekman wrote:
David Culp wrote:
Any Examples of Apache::Filter would be greatly appreciated.
http://www.cpan.org/authors/id/G/GE/GEOFF/Apache-Clean-0.05.tar.gz
p.s. Apache-Clean-2.x is for mp2.
Hmm, now it's impossible to find (or even know that it exists) Apache::Clean for 1.x via the normal tools (other than going to authors/id/G/GE/GEOFF/, but you need to know that it exists). Geoff, I'd suggest that you merge 1.x version in 2.x's version.
I've attached Apache-Peek-2.0-to-be, for one example of how this could be done. Though the obvious problem is that in addition to the inconvenince (the source files aren't .pm and .xs), the users of both versions of mod_perl will have to figure out whether they need to upgrade their installed package, when a new version is released (while the new version is probably changing things only for mp1 or mp2).
Unfortunately we don't get any support from CPAN on this issue :( Better ideas are welcome.
Back to the all-in-one package methodology:
I think that in order to prevent the development inconvenience as it's in the attached Apache-Peek, it's a better approach to have a top level Makefile.PL, which writes a new Makefile.PL in one of the subdirs and takes it from there.
So you have:
If possible, I'd like to present another possible solution as well.
Certainly ;)
One problem with the above is if you need to support people who have both mod_perl 1.x and mod_perl 2.x on the same system (maybe in cases where a company or ISP would need to run both side by side to support both versions.) The end user could change the PREFIX with which the module is installed and modify their lib path appropriately, installing twice - once for each version of mod_perl, but I think that is a little rough on the end user. One trick I used which seems to work pretty well for me is to have one main module that points to two different mod_perl version specific modules based on whether we are running in mod_perl 1.x or 2.x. For example (untested):
in Apache::FooBar.pm:
package Apache::FooBar; use vars qw(@ISA); ... if(eval "Apache::exists_config_define('MODPERL2')") { @ISA = qw(Exporter Apache::FooBar2); require Apache::FooBar2; Apache::FooBar2->import; } else { @ISA = qw(Exporter Apache::FooBar1); require Apache::FooBar1; Apache::FooBar1->import; } 1;
in Apache::FooBar2.pm:
package Apache::FooBar2; use vars qw(@ISA @EXPORT); @ISA = qw(Exporter); @EXPORT = qw(handler); ... sub handler { ... } 1;
But it seems that you are delegating the problem of figuring out what module to load to run-time. We have already committed to having mod_perl 2.0 modules to go to Apache2/ subdir and the Makefile.PL will do that automatically in the future (for those systems where mp2 is in Apache2/) so this is not an issue. Since when you start your mod_perl 2.0 you have 'PerlModule Apache2' it'll pick the right version.
Installation wise, let's take Apache::Peek as an example. It includes two difference implemenations for each modperl. So if we want to install it for mp1 we do:
% perl Makefile.PL && make install
For mp2, we do:
% perl -MApache2 Makefile.PL && make install
and that's all you have to do. The run time will pick the right version.
The only problem is CPAN.pm, which I'm trying to resolve using an env var. In Apache-Peek's Makefile.PL I have:
my %args = map {split /=/, $_ } @ARGV;
if ($ENV{MOD_PERL2} || $args{MOD_PERL2}) {
#warn "Looking for mod_perl 2.0";
require Apache2;
require mod_perl;
if ($mod_perl::VERSION < 1.99) {
die "You don't seem to have mod_perl 2.0 installed";
}
$mp_version = 2;
} else {
require mod_perl;
$mp_version = 1;
}so now if we want to build/install for mp2 we can do:
% perl Makefile.PL MOD_PERL2=1 && make install or % MOD_PERL2=1 perl Makefile.PL MOD_PERL2=1 && make install
So here we have a support for CPAN.
Of course you can start CPAN as:
% perl -MApache2 -MCPAN -eshell
but this is more cumbersome.
(similar thing for Apache::FooBar1.pm)
However this gets cleaner when using method handlers since they don't need to export anything from the mod_perl version specific modules to work (this is similar to what I do in Apache::PAR::Registry):
in Apache::FooBar.pm:
package Apache::FooBar; use vars qw(@ISA); if(eval "Apache::exists_config_define('MODPERL2')") { @ISA = qw(Exporter Apache::FooBar2); require Apache::FooBar2; } else { @ISA = qw(Exporter Apache::FooBar1); require Apache::FooBar1; } 1;
in Apache::FooBar2.pm:
package Apache::FooBar2; ... sub handler : method { my $class = (@_ >= 2) ? shift : __PACKAGE__; my $r = shift; ... } 1;
(similar thing for Apache::FooBar1.pm)
The only problem that I have run into with this is the line: if(eval "Apache::exists_config_define('MODPERL2')") { ... }
This just doesn't seem to be very clean to me, and fails for mod_perl 2.x if the end user doesn't have either a PerlModule Apache::ServerUtil or use Apache::ServerUtil in their Apache configuration, but I haven't yet found a better way to determine the version of mod_perl in all cases (most ways require a request object, which doesn't exist when the module is first used, suggestions welcome.)
yup you have to explicitly require Apache::ServerUtil, without relying on user loading it (you can simply:
eval {require Apache::ServerUtil}
But a much cleaner and simpler way is to just check the VERSION:
require mod_perl;
if ($mod_perl::VERSION < 1.99) {
...
}It looks that we can make it working without adding version numbers to the package names. We just need to work out a clean methodology, convenient to both developers and users.
__________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
