You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by David Culp <dc...@sc.rr.com> on 2003/03/12 02:25:30 UTC
Need Help With Apache::Filter (mod 1.x)
I need help with the Apache::Filter and Apache::OutputChain modules.
I've read all the documentation and review the few examples. I've installed
the modules, but "it is still not working".
What I want to accomplish: I have done via Apache 2.0 mod_ext_filter. However,
I am forced to revert back to Apache 1.3 for other reasons. After much reading much
(mod_perl website,google searches .. and this mailing list (week ago)),
it looks like Apache::Filter and Apache::OutputChain is the only way.
A Quick summary of what I want to do:
* Change the Web Page Body ( i.e. s/something/something else) before it is
sent back to the client.
* This server is primarily a proxy server for the clients
Any Examples of Apache::Filter would be greatly appreciated.
Thanks !
David
Re: CPAN modules which are different for mp1 and mp2...
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> 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.
>
>
> it's probably a bit more complex than I can think of right now, but I'll
> give it some thought. the part that sticks out is the test suite and
> making sure that you can specify different httpd.conf parameters for the
> different installations. there's probably some IfDefine or something
> that can be used, I guess.
<IfDefine !MODPERL2>
...
it's in the porting doc.
> at any rate, I'll give it some thought when I have some time - it's
> difficult for me to dedicate time to even investigating this stuff these
> days, and I usually end up duplicating existing work anyway.
Take your time, Geoff. This was just a suggestion to improve the visibility of
your 1.x version of the module.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN modules which are different for mp1 and mp2...
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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.
it's probably a bit more complex than I can think of right now, but I'll
give it some thought. the part that sticks out is the test suite and making
sure that you can specify different httpd.conf parameters for the different
installations. there's probably some IfDefine or something that can be
used, I guess.
at any rate, I'll give it some thought when I have some time - it's
difficult for me to dedicate time to even investigating this stuff these
days, and I usually end up duplicating existing work anyway.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN modules which are different for mp1 and mp2...
Posted by Stas Bekman <st...@stason.org>.
Nathan Byrd wrote:
> On Tue, 2003-03-11 at 21:23, Stas Bekman wrote:
> [snip]
>
>>> 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.
>
>
> That was actually the point of doing it that way. We then have one set
> of installed modules which can determine their version at run-time,
> instead of having to install two copies of the module. And since the
> use only happens once, there shouldn't be a big performance penalty
> (well, besides any @ISA lookups for inheritance.)
You forget one little thing. That a big chunk of Apache modules are written in
XS. So you can't build two different XS versions at the same time. And even if
you could, what happens if I had only mod_perl 1 and then added mod_perl 2,
after installing module foo? or the other way around? You have to reinstall it
for both of them.
We'd rather have one convention which will work for XS and non-XS modules
(especially since in the future you want want to turn an non-XS module to have
some XS in it).
>>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.
>>
>
>
> Ok, I'm confused. So you mean that using -MApache2 it would install in
> the Apache2 directory, then rely on use Apache2; in the conf to make it
> use the right version (like what is done with the core mod_perl
> modules?) If so I would tend to agree, this is a better idea than doing
> it run-time in most cases. You still have to install the module twice,
> but other than that it would work transparently with two versions of
> Apache/mod_perl on the box (which is really what I was thinking of
> before.)
Yes, that's exactly the idea.
[...]
> Hmm. Not sure that I have any other ideas on this one. Maybe prompt
> (with a timeout?) in the case where -MApache2 was not used or MOD_PERL2
> defined, but both mod_perl 1.x and 2.x are installed? Maybe could also
> allow a MOD_PERL1 just to avoid the prompt for people installing a bunch
> of modules on systems with both.
sure, we can prompt when things aren't specified explicitly and we see that
Apache2 wasn't loaded.
[...]
>>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.
>>
>
>
> For some reason I thought I had tried that and there was a problem with
> checking that way, but when I went back just now and tried again looks
> like that works fine. Thanks!
;)
You probably did, what I did first, doing: $mod_perl::VERSION < 2.0 :)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN modules which are different for mp1 and mp2...
Posted by Nathan Byrd <na...@byrd.net>.
On Tue, 2003-03-11 at 21:23, Stas Bekman wrote:
[snip]
> > 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.
That was actually the point of doing it that way. We then have one set
of installed modules which can determine their version at run-time,
instead of having to install two copies of the module. And since the
use only happens once, there shouldn't be a big performance penalty
(well, besides any @ISA lookups for inheritance.)
> 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.
>
Ok, I'm confused. So you mean that using -MApache2 it would install in
the Apache2 directory, then rely on use Apache2; in the conf to make it
use the right version (like what is done with the core mod_perl
modules?) If so I would tend to agree, this is a better idea than doing
it run-time in most cases. You still have to install the module twice,
but other than that it would work transparently with two versions of
Apache/mod_perl on the box (which is really what I was thinking of
before.)
> 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.
>
Hmm. Not sure that I have any other ideas on this one. Maybe prompt
(with a timeout?) in the case where -MApache2 was not used or MOD_PERL2
defined, but both mod_perl 1.x and 2.x are installed? Maybe could also
allow a MOD_PERL1 just to avoid the prompt for people installing a bunch
of modules on systems with both.
[snip]
> > 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.
>
For some reason I thought I had tried that and there was a problem with
checking that way, but when I went back just now and tried again looks
like that works fine. Thanks!
--
Nathan Byrd <na...@byrd.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN modules which are different for mp1 and mp2...
Posted by Stas Bekman <st...@stason.org>.
Nathan Byrd wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CPAN modules which are different for mp1 and mp2...
Posted by Nathan Byrd <na...@byrd.net>.
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. 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;
(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.)
[snip]
Thanks,
>
> ______________________________________________________________________
--
Nathan Byrd <na...@byrd.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
CPAN modules which are different for mp1 and mp2...
Posted by Stas Bekman <st...@stason.org>.
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:
Apache-Clean/Makefile.PL
Apache-Clean/mp1/Clean.pm
Apache-Clean/mp2/Clean.pm
once Apache-Clean/Makefile.PL figures out it's mp2, it creates:
Apache-Clean/mp2/Makefile.PL and WriteMakefile picks it from there.
In case of Apache::Peek it's more complex, as I have:
Peek.pm.mp1.perl5.5
Peek.pm.mp1.perl5.6
Peek.pm.mp1.perl5.8
Peek.pm.mp2.perl5.6
Peek.pm.mp2.perl5.8
Peek.xs.mp1.perl5.5
Peek.xs.mp1.perl5.6
Peek.xs.mp1.perl5.8
Peek.xs.mp2.perl5.6
Peek.xs.mp2.perl5.8
which I cp into Peek.xs Peek.pm, when the perl and modperl versions are
figured out in Makefile.PL.
I guess I can change it into:
mp1/5.5/Peek.pm
mp1/5.5/Peek.xs
mp1/5.6/Peek.pm
mp1/5.6/Peek.xs
mp1/5.8/Peek.pm
mp2/5.6/Peek.xs
mp2/5.6/Peek.pm
mp1/5.8/Peek.xs
mp1/5.8/Peek.pm
so it'd be easier to maintain.
If you wander why there are so many files, you have to realize that
Apache::Peek is a collection of hacked Devel::Peek which are different in each
perl version. Now we also have different mp2 guts, so here we end up with all
these combinations.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Need Help With Apache::Filter (mod 1.x) - Results
Posted by David Culp <dc...@sc.rr.com>.
> Stas wrote:
>
> http://www.cpan.org/authors/id/G/GE/GEOFF/Apache-Clean-0.05.tar.gz
>
> p.s. Apache-Clean-2.x is for mp2.
>
Thanks Stas !
Looking in the tar file and at modperl_extra.pl, I was able to use
the syntax and methods/properties to update my perl file. I was able to
change some of the Body of my "default page" !
* Now, I need to get it working with Proxy/Reverse Proxy.
(Having issues getting rid of the 'proxy:')
i.e. ProxyPass / http://www.newsite.com/
keeps being sent as proxy:http://www.newsite.com/
* Next, Get it working with SSL
* and Finally using it with RSA SecurID !
[I already have SecurID working - but disabled until the other
items completed]
David
Re: Need Help With Apache::Filter (mod 1.x)
Posted by Stas Bekman <st...@stason.org>.
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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com