You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/02/09 19:38:46 UTC
[mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Stas Bekman wrote:
> Perrin Harkins wrote:
>
>> On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
>>
>>> I now more or less have an idea on how to solve the code usage problem.
>>
>>
>>
>> Great!
>
>
> My idea is replace UNIVERSAL::AUTOLOAD with AUTOLOAD for each class that
> contains objects, so when the method is called on that object it'll do
> just that:
> http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
[...]
OK, here it is. Please give it a try:
Index: lib/ModPerl/WrapXS.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
retrieving revision 1.64
diff -u -u -r1.64 WrapXS.pm
--- lib/ModPerl/WrapXS.pm 31 Jan 2004 10:06:59 -0000 1.64
+++ lib/ModPerl/WrapXS.pm 9 Feb 2004 18:36:02 -0000
@@ -786,6 +786,16 @@
return keys %$methods;
}
+sub avail_modules {
+ my %modules = ();
+ for my $method (keys %$methods) {
+ for my $item ( @{ $methods->{$method} }) {
+ $modules{$item->[MODULE]}++;
+ }
+ }
+ return keys %modules;
+}
+
sub preload_all_modules {
_get_modules() unless $modules;
eval "require $_" for keys %$modules;
Index: src/modules/perl/mod_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.206
diff -u -u -r1.206 mod_perl.c
--- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
+++ src/modules/perl/mod_perl.c 9 Feb 2004 18:36:02 -0000
@@ -246,6 +246,10 @@
av_push(GvAV(PL_incgv),
newSVpv(ap_server_root_relative(p, "lib/perl"), 0));
#endif /* MP_COMPAT_1X */
+
+ /* AUTOLOADs */
+ /* XXX: consider adding a config flag not to preload this module */
+ modperl_require_module(aTHX_ "ModPerl::EazyLife", TRUE);
if (!modperl_config_apply_PerlRequire(s, scfg, perl, p)) {
exit(1);
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ lib/ModPerl/EazyLife.pm 2004-02-03 08:00:34.000000000 -0800
@@ -0,0 +1,19 @@
+package EazyLife;
+
+use ModPerl::MethodLookup ();
+
+for my $module (ModPerl::MethodLookup::avail_modules()) {
+ *{"$module\::AUTOLOAD"} = sub {
+ my($hint, @modules) =
+ ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
+ if (@modules) {
+ eval "require $_" for @modules;
+ goto &$AUTOLOAD;
+ }
+ else {
+ die $hint;
+ }
+ };
+}
+
+1;
______________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Mittwoch, 11. Februar 2004 02:16 schrieb Stas Bekman:
> > Now my error message is
> >
> > Can't locate auto/Apache/Request/PageKit/headers_in.al
> >
> > So I think Apache::Request use a kind of ->can to check for a method
> > before it forwards it. This makes the EazyLife option useless for me. (
> > Or I have to support a kind of autoloader or preloader for my class, but
> > that make it useless too. )
>
> I think not. headers_in called on $r should have AUTOLOADED
> Apache::RequestRec. Now since you call it on Apache::Request::PageKit for
> some reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably
> a problem in either Apache::Request::PageKit or Apache::Request, with
> inheritance gone wrong.
>
Apache::Request::PageKit is my testclass for the port to MP2. It replaces the
old Apache::Request and is @ISA=qw/Apache::Request/;
A:R is unable to use real inherance and forward unknown methods to the
A:R->env object ( that is in my case Apache::RequestRec ). I think it tests
the availability of the method before it calls the method with ->can. And for
that reason it did not find the headers_in method. Since it is not loaded.
But that is untested so far.
> Does it work for you if you use a pure modperl handler/registry script?
More tomorrow; its to late already ( 3:01:33 )
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
>>>what if my class is
>>>
>>>package q;
>>>@ISA=('Apache::Filter', 'Apache::RequestIO');
>>>
>>>or look at DESTROY do we choice the right DESTROY?
>
>
> some what related:
> perl -MModPerl::MethodLookup -le ' \
> package Apache::RequestRec; sub new { bless {}, shift }; 1; \
> package My::Request; @ISA = qw(Apache::RequestRec); 1; \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY", $obj); \
> print $hint'
>
> To use method 'DESTROY' add:
> use APR::Pool ();
>
> but
>
> perl -MModPerl::MethodLookup -le ' \
> package Apache::RequestRec; sub new { bless {}, shift }; 1; \
> package My::Request; @ISA = qw(Apache::RequestRec); 1; \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY",
> "Apache::RequestRec"); \ print $hint'
>
> gives nothing.
I think it handles it correctly now. In prints now:
Several modules (APR::ThreadMutex, Apache::SubRequest, APR::Pool) contain
method 'DESTROY' but none of them matches class 'My::Request';
Several modules (APR::ThreadMutex, Apache::SubRequest, APR::Pool) contain
method 'DESTROY' but none of them matches class 'Apache::RequestRec';
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Mittwoch, 18. Februar 2004 00:37 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>
> [...]
>
>>>>>my $c = shift;
>>>>>$AUTOLOAD =~ /(\w+)$/;
>>>>>$c->$1(@_);
>>>>>
>>>>>looks funny, but the we need to handle the return part too. That might
>>>>>be not so nice for any case.
>>>>
>>>>Yes, that's not good. How about:
>>>>
>>>> if (@modules) {
>>>> eval "require $_" for @modules;
>>>> if (@modules == 1) {
>>>> my $module = shift @modules;
>>>> $AUTOLOAD =~ s/.*::/$module::/;
>>>> }
>>>> goto &$AUTOLOAD;
>>>> }
>>>>
>>>>really, I think it should always be only one matching module, since we
>>>>have no internal sub-classing at the moment.
>>>
>>>I can not belive, that this work.
>>
>>You mean it *does* work for you.
>
>
> No, it does not work.
Let me know if does work now, and if not what does not. Thanks.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Mittwoch, 18. Februar 2004 00:37 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >>>my $c = shift;
> >>>$AUTOLOAD =~ /(\w+)$/;
> >>>$c->$1(@_);
> >>>
> >>>looks funny, but the we need to handle the return part too. That might
> >>> be not so nice for any case.
> >>
> >>Yes, that's not good. How about:
> >>
> >> if (@modules) {
> >> eval "require $_" for @modules;
> >> if (@modules == 1) {
> >> my $module = shift @modules;
> >> $AUTOLOAD =~ s/.*::/$module::/;
> >> }
> >> goto &$AUTOLOAD;
> >> }
> >>
> >>really, I think it should always be only one matching module, since we
> >> have no internal sub-classing at the moment.
> >
> > I can not belive, that this work.
>
> You mean it *does* work for you.
No, it does not work.
>
> > what if my class is
> >
> > package q;
> > @ISA=('Apache::Filter', 'Apache::RequestIO');
> >
> > or look at DESTROY do we choice the right DESTROY?
some what related:
perl -MModPerl::MethodLookup -le ' \
package Apache::RequestRec; sub new { bless {}, shift }; 1; \
package My::Request; @ISA = qw(Apache::RequestRec); 1; \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY", $obj); \
print $hint'
To use method 'DESTROY' add:
use APR::Pool ();
but
perl -MModPerl::MethodLookup -le ' \
package Apache::RequestRec; sub new { bless {}, shift }; 1; \
package My::Request; @ISA = qw(Apache::RequestRec); 1; \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY",
"Apache::RequestRec"); \ print $hint'
gives nothing.
>
> that is easily solvable by passing the class name the AUTOLOAD is called
> for instead of the real object.
>
> So if you call:
>
> package q;
> @ISA=('Apache::Filter', 'Apache::RequestIO');
> q->new->print();
>
> we do:
>
> for my $module (@avail_modules) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, $module);
>
> which translates into:
>
> lookup_method('q::print', 'Apache::Filter');
>
> since inheritance tree traversal goes left to right. Meaning that it'll
> find that Apache::Filter need to be loaded and then call:
>
> goto &Apache::Filter::print;
>
> The problem with that change is when a method which is not found in the
> first ISA class is not found. Actually the way lookup_method is implemented
> at the moment, it'll check the second argument only if it has more than 1
> hit. So if you call:
>
> q->new->sendfile();
>
> it'll still do the right thing. Apache::Filter::AUTOLOAD will load
> Apache::RequestIO and call:
>
> goto &Apache::RequestIO::sendfile;
>
> Regarding DESTROY, I think we are covered too. The only difference from the
> above explanation is that we don't croak if DESTROY is not found. Or do you
> see a hole in my logic?
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Dienstag, 17. Februar 2004 03:06 schrieb Stas Bekman:
>
>>>something like
>>>
>>>my $c = shift;
>>>$AUTOLOAD =~ /(\w+)$/;
>>>$c->$1(@_);
>>>
>>>looks funny, but the we need to handle the return part too. That might be
>>>not so nice for any case.
>>
>>Yes, that's not good. How about:
>>
>> if (@modules) {
>> eval "require $_" for @modules;
>> if (@modules == 1) {
>> my $module = shift @modules;
>> $AUTOLOAD =~ s/.*::/$module::/;
>> }
>> goto &$AUTOLOAD;
>> }
>>
>>really, I think it should always be only one matching module, since we have
>>no internal sub-classing at the moment.
>
>
> I can not belive, that this work.
You mean it *does* work for you.
> what if my class is
>
> package q;
> @ISA=('Apache::Filter', 'Apache::RequestIO');
>
> or look at DESTROY do we choice the right DESTROY?
that is easily solvable by passing the class name the AUTOLOAD is called for
instead of the real object.
So if you call:
package q;
@ISA=('Apache::Filter', 'Apache::RequestIO');
q->new->print();
we do:
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, $module);
which translates into:
lookup_method('q::print', 'Apache::Filter');
since inheritance tree traversal goes left to right. Meaning that it'll find
that Apache::Filter need to be loaded and then call:
goto &Apache::Filter::print;
The problem with that change is when a method which is not found in the first
ISA class is not found. Actually the way lookup_method is implemented at the
moment, it'll check the second argument only if it has more than 1 hit. So if
you call:
q->new->sendfile();
it'll still do the right thing. Apache::Filter::AUTOLOAD will load
Apache::RequestIO and call:
goto &Apache::RequestIO::sendfile;
Regarding DESTROY, I think we are covered too. The only difference from the
above explanation is that we don't croak if DESTROY is not found. Or do you
see a hole in my logic?
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Dienstag, 17. Februar 2004 03:06 schrieb Stas Bekman:
> > something like
> >
> > my $c = shift;
> > $AUTOLOAD =~ /(\w+)$/;
> > $c->$1(@_);
> >
> > looks funny, but the we need to handle the return part too. That might be
> > not so nice for any case.
>
> Yes, that's not good. How about:
>
> if (@modules) {
> eval "require $_" for @modules;
> if (@modules == 1) {
> my $module = shift @modules;
> $AUTOLOAD =~ s/.*::/$module::/;
> }
> goto &$AUTOLOAD;
> }
>
> really, I think it should always be only one matching module, since we have
> no internal sub-classing at the moment.
I can not belive, that this work. what if my class is
package q;
@ISA=('Apache::Filter', 'Apache::RequestIO');
or look at DESTROY do we choice the right DESTROY?
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Donnerstag, 19. Februar 2004 11:03 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>>[...]
>>
>>
>>>>i.e. I can't reproduce your problem. Are you sure you are using the
>>>>latest cvs, did you run 'make install'?. There were quite a few changes
>>>>in the APR::Pool code over the last month.
>>>
>>>Yes, Im sure. But for some reason It did not crash for me too. I
>>>investigate.
>>
>>that's a good news (for me, hopefully no guessing will be needed). Now you
>>need to figure out how to make it crash, and hopefully it'll crash for me
>>too ;)
>
>
> It was easy, install this EazyLife too.
Ouch, of course ;)
The problem was due to a silly bug I've introduced in the lookup_method
function, matching the object to itself ;) Now should be fixed.
I was getting a segfault in the ModPerl-Registry's make test, but in
APR::ThreadMutex::DESTROY as I suppose my perl put that package before
APR::Pool ;)
'DESTROY' => [
[
'APR::ThreadMutex',
'APR::ThreadMutex'
],
[
'Apache::SubRequest',
'Apache::SubRequest'
],
[
'APR::Pool',
'APR::Pool'
]
],
So for me it was resolving Apache::Server::DESTROY as
APR::ThreadMutex::DESTROY and boom...
It should be fine in the cvs right now, I think.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Donnerstag, 19. Februar 2004 11:03 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> >>i.e. I can't reproduce your problem. Are you sure you are using the
> >> latest cvs, did you run 'make install'?. There were quite a few changes
> >> in the APR::Pool code over the last month.
> >
> > Yes, Im sure. But for some reason It did not crash for me too. I
> > investigate.
>
> that's a good news (for me, hopefully no guessing will be needed). Now you
> need to figure out how to make it crash, and hopefully it'll crash for me
> too ;)
It was easy, install this EazyLife too.
package ModPerl::EazyLife;
use ModPerl::MethodLookup ();
use Carp;
my @avail_modules = ModPerl::MethodLookup::avail_modules();
push @avail_modules, 'Apache'; # XXX: may go away
my $skip = qr|(::)?DESTROY$|;
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
# there should be only one match
if (my ($module) = @modules) {
eval "require $module";
# use the function from the module that we have just loaded
$AUTOLOAD =~ s/^.*::/${module}::/;
goto &$AUTOLOAD;
}
else {
return if $AUTOLOAD =~ /$skip/;
croak $hint || "Can't find $AUTOLOAD";
}
};
}
1;
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
>>i.e. I can't reproduce your problem. Are you sure you are using the latest
>>cvs, did you run 'make install'?. There were quite a few changes in the
>>APR::Pool code over the last month.
>>
>
>
> Yes, Im sure. But for some reason It did not crash for me too. I investigate.
that's a good news (for me, hopefully no guessing will be needed). Now you
need to figure out how to make it crash, and hopefully it'll crash for me too ;)
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Am Donnerstag, 19. Februar 2004 09:51 schrieb Stas Bekman:
> Boris Zentner wrote:
> > Hi Stas,
> >
> > Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
> >>>(gdb) bt
> >>>#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
> >>>val=0x0) at apr_hash.c:278
> >>>#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
> >>> at apr_hash.c:340
> >>>#2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
> >>> key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
> >>
> >>the pool object is bogus.
> >>
> >>>#3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
> >>> from
> >>>/home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/
> >>>P ool/Pool.so #4 0x4042c3b9 in Perl_pp_goto ()
> >>> from
> >>>/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so #5
> >>> 0x403f803e in Perl_runops_standard ()
> >>
> >>I've seen that one before. Can you show me a short code that I can
> >>reproduce this with?
> >
> > Ok, here it is ( minimal and useless ):
> >
> > I use './t/TEST --start-httpd' the server.
> >
> > My ./t/conf/extra.last.conf.in:
> > ######### START ##########
> > <Perl >
> >
> > </Perl>
> >
> > <Location />
> > SetHandler perl-script
> > PerlHandler +Foo
> > </Location>
> > ######### END ############
> > without the ### lines of course. Please note that the whitespace chars
> > are important. If you write
> >
> > <Perl >
> > </Perl>
> >
> > it works! ( Just a newline removed )
> >
> > and Foo.pm
> > ######### START ##########
> > package Foo;
> > use mod_perl 1.99;
> > sub handler : method {
> > my ( $class, $r ) = @_ ;
> > return 200;
> > }
> > ######### END ############
>
> OK, I've packaged your test case for you in self-contained test suite
> (attached as it's a tiny file).
>
thanks
> % tar xvzf apr-destroy.tgs
> % cd apr-destroy
> % perl Makefile.PL -httpd ~/httpd/prefork/bin/httpd && t/TEST -start
> Writing Makefile for bug-reporting-skeleton
> setting ulimit to allow core files
> ulimit -c unlimited; t/TEST -start
> server localhost.localdomain:8529 shutdown
> /home/stas/httpd/prefork/bin/httpd -d /tmp/apr-destroy/t -f
> /tmp/apr-destroy/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
> using Apache/2.0.49-dev (prefork MPM)
> waiting 60 seconds for server to start: ok (waited 6 secs)
> server localhost.localdomain:8529 started
>
> i.e. I can't reproduce your problem. Are you sure you are using the latest
> cvs, did you run 'make install'?. There were quite a few changes in the
> APR::Pool code over the last month.
>
Yes, Im sure. But for some reason It did not crash for me too. I investigate.
> Try to run this test suite and see what you get. Here is what I used for
> this test:
>
> % mp2bug
here is my output from mp2bug.
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** mod_perl version 1.9913
***
using /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX => /home/ptest2/httpd2
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /home/ptest2/httpd2/bin/httpd -V
Server version: Apache/2.0.47
Server built: Oct 13 2003 17:19:44
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/home/ptest2/httpd2"
-D SUEXEC_BIN="/home/ptest2/httpd2/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /home/ptest2/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.21-99-default, archname=i686-linux-thread-multi
uname='linux foo 2.4.21-99-default #1 wed sep 24 13:30:51 utc 2003 i686
i686 i386 gnulinux '
config_args='-Dprefix=/home/ptest2 -Uversiononly -Dusethreads
-Duseshrplib=true -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.1 (SuSE Linux)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Oct 13 2003 16:28:01
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi
/home/ptest2/lib/perl5/5.8.1
/home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi
/home/ptest2/lib/perl5/site_perl/5.8.1
/home/ptest2/lib/perl5/site_perl
.
*** Packages of interest status:
Apache::Request: 2.02-dev
CGI : 3.00
LWP : 5.69
mod_perl : 1.9913
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by /home/ptest2/bin/mp2bug on Thu Feb 19 09:54:52
2004 GMT.
[ your example removed ]
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
>
>>>(gdb) bt
>>>#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
>>>val=0x0) at apr_hash.c:278
>>>#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
>>> at apr_hash.c:340
>>>#2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
>>> key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
>>
>>the pool object is bogus.
>>
>>
>>>#3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
>>> from
>>>/home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/P
>>>ool/Pool.so #4 0x4042c3b9 in Perl_pp_goto ()
>>> from
>>>/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so #5
>>> 0x403f803e in Perl_runops_standard ()
>>
>>I've seen that one before. Can you show me a short code that I can
>>reproduce this with?
>
>
> Ok, here it is ( minimal and useless ):
>
> I use './t/TEST --start-httpd' the server.
>
> My ./t/conf/extra.last.conf.in:
> ######### START ##########
> <Perl >
>
> </Perl>
>
> <Location />
> SetHandler perl-script
> PerlHandler +Foo
> </Location>
> ######### END ############
> without the ### lines of course. Please note that the whitespace chars are
> important. If you write
>
> <Perl >
> </Perl>
>
> it works! ( Just a newline removed )
>
> and Foo.pm
> ######### START ##########
> package Foo;
> use mod_perl 1.99;
> sub handler : method {
> my ( $class, $r ) = @_ ;
> return 200;
> }
> ######### END ############
>
OK, I've packaged your test case for you in self-contained test suite
(attached as it's a tiny file).
% tar xvzf apr-destroy.tgs
% cd apr-destroy
% perl Makefile.PL -httpd ~/httpd/prefork/bin/httpd && t/TEST -start
Writing Makefile for bug-reporting-skeleton
setting ulimit to allow core files
ulimit -c unlimited; t/TEST -start
server localhost.localdomain:8529 shutdown
/home/stas/httpd/prefork/bin/httpd -d /tmp/apr-destroy/t -f
/tmp/apr-destroy/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.49-dev (prefork MPM)
waiting 60 seconds for server to start: ok (waited 6 secs)
server localhost.localdomain:8529 started
i.e. I can't reproduce your problem. Are you sure you are using the latest
cvs, did you run 'make install'?. There were quite a few changes in the
APR::Pool code over the last month.
Try to run this test suite and see what you get. Here is what I used for this
test:
% mp2bug
*** mod_perl version 1.9913
*** using
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache2/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS => /home/stas/httpd/prefork/bin/apxs
MP_CCOPTS => -Wall -Werror
MP_COMPAT_1X => 1
MP_DEBUG => 1
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_MAINTAINER => 1
MP_TRACE => 1
MP_USE_DSO => 1
MP_USE_GTOP => 1
*** /home/stas/httpd/prefork/bin/httpd -V
Server version: Apache/2.0.49-dev
Server built: Feb 18 2004 15:04:02
Server's Module Magic Number: 20020903:7
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/home/stas/httpd/prefork"
-D SUEXEC_BIN="/home/stas/httpd/prefork/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.6.0-1mdkenterprise, archname=i386-linux-thread-multi
uname='linux no.mandrakesoft.com 2.6.0-1mdkenterprise #1 smp thu dec 18
16:11:28 est 2003 i686 unknown unknown gnulinux '
config_args='-des -Dinc_version_list=5.8.2/i386-linux-thread-multi 5.8.2
5.8.1/i386-linux-thread-multi 5.8.1 5.8.0/i386-linux-thread-multi 5.8.0 5.6.1
5.6.0 -Darchname=i386-linux -Dcc=gcc -Doptimize=-O2 -fomit-frame-pointer -pipe
-march=i586 -mcpu=pentiumpro -Dprefix=/usr -Dvendorprefix=/usr
-Dsiteprefix=/usr -Dman3ext=3pm -Dcf_by=MandrakeSoft -Dmyhostname=localhost
-Dperladmin=root@localhost -Dd_dosuid -Ud_csh -Duseshrplib -Dusethreads'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro ',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Feb 3 2004 13:50:20
%ENV:
PERLDOC_PAGER="less -R"
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/lib/perl5/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/5.8.3
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.
*** Packages of interest status:
Apache::Request: -
CGI : 3.00
LWP : 5.69
mod_perl : 1.2801, 1.9913
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
> > (gdb) bt
> > #0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
> > val=0x0) at apr_hash.c:278
> > #1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
> > at apr_hash.c:340
> > #2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
> > key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
>
> the pool object is bogus.
>
> > #3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
> > from
> > /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/P
> >ool/Pool.so #4 0x4042c3b9 in Perl_pp_goto ()
> > from
> > /home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so #5
> > 0x403f803e in Perl_runops_standard ()
>
> I've seen that one before. Can you show me a short code that I can
> reproduce this with?
Ok, here it is ( minimal and useless ):
I use './t/TEST --start-httpd' the server.
My ./t/conf/extra.last.conf.in:
######### START ##########
<Perl >
</Perl>
<Location />
SetHandler perl-script
PerlHandler +Foo
</Location>
######### END ############
without the ### lines of course. Please note that the whitespace chars are
important. If you write
<Perl >
</Perl>
it works! ( Just a newline removed )
and Foo.pm
######### START ##########
package Foo;
use mod_perl 1.99;
sub handler : method {
my ( $class, $r ) = @_ ;
return 200;
}
######### END ############
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> HI Stas,
>
> this has its problems too. It dumps core. After starting a server I see:
>
> Apache::Server::DESTROY
>
> lookup_method finds APR::Pool. And so we call
>
> APR::Pool::DESTROY
>
> this does not look wrong to me, if APR::Pool has a DESTROY function and
> Apache::Server isa APR::Pool.
>
> here a small part from my coredump.
>
> (gdb) bt
> #0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14, val=0x0)
> at apr_hash.c:278
> #1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
> at apr_hash.c:340
> #2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
> key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
the pool object is bogus.
> #3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
> from /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/Pool/Pool.so
> #4 0x4042c3b9 in Perl_pp_goto ()
> from /home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so
> #5 0x403f803e in Perl_runops_standard ()
I've seen that one before. Can you show me a short code that I can reproduce
this with?
> and some typos fixed in the test ModPerl::EazyLife.
thanks ;)
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
HI Stas,
this has its problems too. It dumps core. After starting a server I see:
Apache::Server::DESTROY
lookup_method finds APR::Pool. And so we call
APR::Pool::DESTROY
this does not look wrong to me, if APR::Pool has a DESTROY function and
Apache::Server isa APR::Pool.
here a small part from my coredump.
(gdb) bt
#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14, val=0x0)
at apr_hash.c:278
#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
at apr_hash.c:340
#2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
#3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
from /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/Pool/Pool.so
#4 0x4042c3b9 in Perl_pp_goto ()
from /home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so
#5 0x403f803e in Perl_runops_standard ()
and some typos fixed in the test ModPerl::EazyLife.
Am Dienstag, 17. Februar 2004 03:12 schrieb Stas Bekman:
> Stas Bekman wrote:
> [...]
>
> > really, I think it should always be only one matching module, since we
> > have no internal sub-classing at the moment.
>
> Something like so:
>
> package ModPerl::EazyLife;
>
> use ModPerl::MethodLookup ();
> use Carp;
>
> my @avail_modules = ModPerl::MethodLookup::avail_modules();
> push @avail_modules, 'Apache'; # XXX: may go away
> my $skip = qr|(::)?DESTROY$|;
> for my $module (@avail_modules) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> # there should be only one match
> if (my $module = @modules) {
- if (my $module = @modules) {
+ if (my ($module) = @modules) {
> eval "require $module";
> # use the function from the module that we have just loaded
> $AUTOLOAD =~ s/.*::/$module::/;
- $AUTOLOAD =~ s/.*::/$module::/;
+ $AUTOLOAD =~ s/.*::/${module}::/;
> goto &$AUTOLOAD;
> }
> else {
> return if $AUTOLOAD =~ /$skip/;
> croak $hint || "Can't find $AUTOLOAD";
> }
> };
> }
>
> 1;
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> really, I think it should always be only one matching module, since we
> have no internal sub-classing at the moment.
Something like so:
package ModPerl::EazyLife;
use ModPerl::MethodLookup ();
use Carp;
my @avail_modules = ModPerl::MethodLookup::avail_modules();
push @avail_modules, 'Apache'; # XXX: may go away
my $skip = qr|(::)?DESTROY$|;
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
# there should be only one match
if (my $module = @modules) {
eval "require $module";
# use the function from the module that we have just loaded
$AUTOLOAD =~ s/.*::/$module::/;
goto &$AUTOLOAD;
}
else {
return if $AUTOLOAD =~ /$skip/;
croak $hint || "Can't find $AUTOLOAD";
}
};
}
1;
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
Earlier you've raised an important point: AUTOLOADs slow things down with
DESTROY and evals, penalizing users who don't rely on this module.
In order not to penalize those who preload, I think that we need to somehow
undef AUTOLOADs as soon as the module is loaded. Though this is tricky with
cases like Apache::RequestRec, since Apache::RequestRec::AUTOLOAD handles
several other classes.
Ideas?
>>>>so lookup_method internally finds two entries. none of them matches
>>>>My::RequestRec. So it checks isa() and finds that the first entry
>>>>matches. It should now return 'Apache::RequestIO', which AUTOLOAD loads
>>>>and now when it calls goto, it calls that method.
>>>
>>>Yes, that is exactly what happened here. But it is wrong.
>>>from your example:
>>> Apache::RequestIO is returned. now
>>> eval { require 'Apache::RequestIO' } loads the class/package.
>>>
>>>but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and
>>>produce the endless loop. Since we need to call Apache::RequestRec::print
>>>_not_ My::RequestRec::print.
>>
>>I see. So we probably need to call:
>>
>>shift->$AUTOLOAD
>>
>
>
> something like
>
> my $c = shift;
> $AUTOLOAD =~ /(\w+)$/;
> $c->$1(@_);
>
> looks funny, but the we need to handle the return part too. That might be not
> so nice for any case.
Yes, that's not good. How about:
if (@modules) {
eval "require $_" for @modules;
if (@modules == 1) {
my $module = shift @modules;
$AUTOLOAD =~ s/.*::/$module::/;
}
goto &$AUTOLOAD;
}
really, I think it should always be only one matching module, since we have no
internal sub-classing at the moment.
>>then? which this time will find print() on its own, since Apache::RequestIO
>>is now loaded.
>>
>>Not sure about the AUTOLOAD goto magick though. Ideas?
>>
>>May be having method_lookup return the package name will allow us to call:
>>
>> Apache::RequestRec::print(@_);
>>
>>But if there is a way to call the object method via goto, that would be the
>>simplest way.
>>
>
>
> Without too much thinking I prefere if method_lookup would return the full
> qualified method name ( Apache::RequestRec::print ).
>
> Then we can call goto &$method.
That will probably require writing a new function, as this extra return
argument doesn't fit into the existing API. I think a simple s/// above should
do the trick.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Montag, 16. Februar 2004 12:39 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> >>so lookup_method internally finds two entries. none of them matches
> >>My::RequestRec. So it checks isa() and finds that the first entry
> >> matches. It should now return 'Apache::RequestIO', which AUTOLOAD loads
> >> and now when it calls goto, it calls that method.
> >
> > Yes, that is exactly what happened here. But it is wrong.
> > from your example:
> > Apache::RequestIO is returned. now
> > eval { require 'Apache::RequestIO' } loads the class/package.
> >
> > but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and
> > produce the endless loop. Since we need to call Apache::RequestRec::print
> > _not_ My::RequestRec::print.
>
> I see. So we probably need to call:
>
> shift->$AUTOLOAD
>
something like
my $c = shift;
$AUTOLOAD =~ /(\w+)$/;
$c->$1(@_);
looks funny, but the we need to handle the return part too. That might be not
so nice for any case.
> then? which this time will find print() on its own, since Apache::RequestIO
> is now loaded.
>
> Not sure about the AUTOLOAD goto magick though. Ideas?
>
> May be having method_lookup return the package name will allow us to call:
>
> Apache::RequestRec::print(@_);
>
> But if there is a way to call the object method via goto, that would be the
> simplest way.
>
Without too much thinking I prefere if method_lookup would return the full
qualified method name ( Apache::RequestRec::print ).
Then we can call goto &$method.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
>>Users who are after performance must not be penalized with this module
>>being preloaded. So it should be configurable, with default to be On.
>>
>>We probabably can instrument EazyLife to dump a list of modules, that it
>>has loaded during the scripts execution, on the server shutdown, to make it
>>easier for the users to know which modules to preload and eventually get
>>rid of EazyLife.
>>
>>PerlEazyLife <Off|On|OnInfo>
>
> That is a really usefull extension.
What is? The dump of the loaded modules or the configure option, or both?
> I thought of it, but I do not dare to ask
> for it.
What you do you mean, you don't dare to ask for it. You can even code it ;)
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Mittwoch, 18. Februar 2004 00:47 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> Users who are after performance must not be penalized with this module
> being preloaded. So it should be configurable, with default to be On.
>
> We probabably can instrument EazyLife to dump a list of modules, that it
> has loaded during the scripts execution, on the server shutdown, to make it
> easier for the users to know which modules to preload and eventually get
> rid of EazyLife.
>
> PerlEazyLife <Off|On|OnInfo>
>
That is a really usefull extension. I thought of it, but I do not dare to ask
for it.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Montag, 16. Februar 2004 11:58 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>>[...]
>>
>>
>>>It works better, but not right. It has the same problems as the last one,
>>>but the other way around ;-)
>>>
>>>On my first test I found out that it is incredible slow. So iI move the
>>>
>>> return if $AUTOLOAD =~ /$skip/;
>>>
>>>line before the lookup_method. That is not right ever, your way looks
>>>much better, but it was so slow. Perhaps other ideas are around.
>>
>>What's slow? Are there too many calls to DESTROY? Can you add tracing to
>>figure out the reason?
>
>
> It was so slow that I thought it is not working at all. Yes it was eval and
> destroy. But I take a closer look later.
Users who are after performance must not be penalized with this module being
preloaded. So it should be configurable, with default to be On.
We probabably can instrument EazyLife to dump a list of modules, that it has
loaded during the scripts execution, on the server shutdown, to make it easier
for the users to know which modules to preload and eventually get rid of EazyLife.
PerlEazyLife <Off|On|OnInfo>
Also another way to deal with DESTROY calls is to autovivify them as noops.
my $noop = sub () {};
...
goto &$noop if /DESTROY$/;
or even:
use constant NOOP => '';
...
goto &NOOP if /DESTROY$/;
does this speed things up?
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
>>so lookup_method internally finds two entries. none of them matches
>>My::RequestRec. So it checks isa() and finds that the first entry matches.
>>It should now return 'Apache::RequestIO', which AUTOLOAD loads and now when
>>it calls goto, it calls that method.
>
>
> Yes, that is exactly what happened here. But it is wrong.
> from your example:
> Apache::RequestIO is returned. now
> eval { require 'Apache::RequestIO' } loads the class/package.
>
> but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and produce
> the endless loop. Since we need to call Apache::RequestRec::print _not_
> My::RequestRec::print.
I see. So we probably need to call:
shift->$AUTOLOAD
then? which this time will find print() on its own, since Apache::RequestIO is
now loaded.
Not sure about the AUTOLOAD goto magick though. Ideas?
May be having method_lookup return the package name will allow us to call:
Apache::RequestRec::print(@_);
But if there is a way to call the object method via goto, that would be the
simplest way.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Montag, 16. Februar 2004 11:58 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> > It works better, but not right. It has the same problems as the last one,
> > but the other way around ;-)
> >
> > On my first test I found out that it is incredible slow. So iI move the
> >
> > return if $AUTOLOAD =~ /$skip/;
> >
> > line before the lookup_method. That is not right ever, your way looks
> > much better, but it was so slow. Perhaps other ideas are around.
>
> What's slow? Are there too many calls to DESTROY? Can you add tracing to
> figure out the reason?
It was so slow that I thought it is not working at all. Yes it was eval and
destroy. But I take a closer look later.
>
> I thought to do so originally (move it up), but there are DESTROY methods
> in some of the classes, so I don't think this is right (unless we manually
> look them up and cache and then skip lookup if it's not in the cache.
>
> > The second problem is if I have a class that inherits from another class
> > with splitted functions like Apache::RequestRec.
> >
> > package xxx;
> > @ISA='Apache::RequestRec';
> > sub new { bless $_[1], $_[0] }
> >
> > sub handler : method {
> > my ( $class, $rec ) = @_;
> > xxx->new( $rec )->print('hello world');
> > }
> >
> > then AUTOLOAD is called and found out, that Apache::RequestRec is the
> > superclass of xxx and that Apache::RequestIO must be loaded. We require
> > Apache::RequestRec and then goto subroutine xxx::print. That is an
> > endless loop, since it calls AUTOLOAD to find out about xxx::print. In
> > this case we must call Apache::RequestRec::print, but we do not know
> > about it we only know Apache::RequestIO.
>
> So there must be a bug in the code. That shouldn't be the case. Let's take
> the $obj->print() call for example. where $obj is a sub-class of
> Apache::RequestRec and let's say it's called My::RequestRec. The data we
> have is:
>
> 'print' => [
> [
> 'Apache::RequestIO',
> 'Apache::RequestRec'
> ],
> [
> 'Apache::Filter',
> 'Apache::Filter'
> ]
> ],
>
> so lookup_method internally finds two entries. none of them matches
> My::RequestRec. So it checks isa() and finds that the first entry matches.
> It should now return 'Apache::RequestIO', which AUTOLOAD loads and now when
> it calls goto, it calls that method.
Yes, that is exactly what happened here. But it is wrong.
from your example:
Apache::RequestIO is returned. now
eval { require 'Apache::RequestIO' } loads the class/package.
but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and produce
the endless loop. Since we need to call Apache::RequestRec::print _not_
My::RequestRec::print.
>
> This snippet I've quoted earlier shows that method_lookup returns
> 'Apache::RequestIO'
>
> perl -MModPerl::MethodLookup -le '\
> package Apache::RequestRec; sub new { bless {}, shift }; \
> package My::Request; @ISA = qw(Apache::RequestRec); \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj);
> \ print $hint'
> To use method 'print' add:
> use Apache::RequestIO ();
>
> What do you see different?
I see exactly what you see.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
> It works better, but not right. It has the same problems as the last one, but
> the other way around ;-)
>
> On my first test I found out that it is incredible slow. So iI move the
>
> return if $AUTOLOAD =~ /$skip/;
>
> line before the lookup_method. That is not right ever, your way looks much
> better, but it was so slow. Perhaps other ideas are around.
What's slow? Are there too many calls to DESTROY? Can you add tracing to
figure out the reason?
I thought to do so originally (move it up), but there are DESTROY methods in
some of the classes, so I don't think this is right (unless we manually look
them up and cache and then skip lookup if it's not in the cache.
> The second problem is if I have a class that inherits from another class with
> splitted functions like Apache::RequestRec.
>
> package xxx;
> @ISA='Apache::RequestRec';
> sub new { bless $_[1], $_[0] }
>
> sub handler : method {
> my ( $class, $rec ) = @_;
> xxx->new( $rec )->print('hello world');
> }
>
> then AUTOLOAD is called and found out, that Apache::RequestRec is the
> superclass of xxx and that Apache::RequestIO must be loaded. We require
> Apache::RequestRec and then goto subroutine xxx::print. That is an endless
> loop, since it calls AUTOLOAD to find out about xxx::print. In this case we
> must call Apache::RequestRec::print, but we do not know about it we only know
> Apache::RequestIO.
So there must be a bug in the code. That shouldn't be the case. Let's take the
$obj->print() call for example. where $obj is a sub-class of
Apache::RequestRec and let's say it's called My::RequestRec. The data we have is:
'print' => [
[
'Apache::RequestIO',
'Apache::RequestRec'
],
[
'Apache::Filter',
'Apache::Filter'
]
],
so lookup_method internally finds two entries. none of them matches
My::RequestRec. So it checks isa() and finds that the first entry matches. It
should now return 'Apache::RequestIO', which AUTOLOAD loads and now when it
calls goto, it calls that method.
This snippet I've quoted earlier shows that method_lookup returns
'Apache::RequestIO'
perl -MModPerl::MethodLookup -le '\
package Apache::RequestRec; sub new { bless {}, shift }; \
package My::Request; @ISA = qw(Apache::RequestRec); \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj); \
print $hint'
To use method 'print' add:
use Apache::RequestIO ();
What do you see different?
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Freitag, 13. Februar 2004 23:56 schrieb Stas Bekman:
> I've extended lookup_method to support sub-classed objects. which
> simplifies the usage. It's now committed. Here is a test:
>
> perl -MModPerl::MethodLookup -le '\
> package Apache::RequestRec; sub new { bless {}, shift }; \
> package My::Request; @ISA = qw(Apache::RequestRec); \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj);
> \ print $hint'
> To use method 'print' add:
> use Apache::RequestIO ();
>
> So EazyLife.pm, including fixes for your previous comments, looks like:
>
It works better, but not right. It has the same problems as the last one, but
the other way around ;-)
On my first test I found out that it is incredible slow. So iI move the
return if $AUTOLOAD =~ /$skip/;
line before the lookup_method. That is not right ever, your way looks much
better, but it was so slow. Perhaps other ideas are around.
The second problem is if I have a class that inherits from another class with
splitted functions like Apache::RequestRec.
package xxx;
@ISA='Apache::RequestRec';
sub new { bless $_[1], $_[0] }
sub handler : method {
my ( $class, $rec ) = @_;
xxx->new( $rec )->print('hello world');
}
then AUTOLOAD is called and found out, that Apache::RequestRec is the
superclass of xxx and that Apache::RequestIO must be loaded. We require
Apache::RequestRec and then goto subroutine xxx::print. That is an endless
loop, since it calls AUTOLOAD to find out about xxx::print. In this case we
must call Apache::RequestRec::print, but we do not know about it we only know
Apache::RequestIO.
> package ModPerl::EazyLife;
>
> use ModPerl::MethodLookup ();
> use Carp;
>
> my @avail_modules = ModPerl::MethodLookup::avail_modules();
> push @avail_modules, 'Apache'; # XXX: may go away
> my $skip = qr|(::)?DESTROY$|;
> for my $module (@avail_modules) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> if (@modules) {
> eval "require $_" for @modules;
> goto &$AUTOLOAD;
> }
> else {
> return if $AUTOLOAD =~ /$skip/;
> croak $hint || "Can't find $AUTOLOAD";
> }
> };
> }
>
> 1;
>
> You need to update your cvs and rebuild (because of the changes in the
> autogenerated MethodLookup.pm module).
>
Have a nice day.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
I've extended lookup_method to support sub-classed objects. which simplifies
the usage. It's now committed. Here is a test:
perl -MModPerl::MethodLookup -le '\
package Apache::RequestRec; sub new { bless {}, shift }; \
package My::Request; @ISA = qw(Apache::RequestRec); \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj); \
print $hint'
To use method 'print' add:
use Apache::RequestIO ();
So EazyLife.pm, including fixes for your previous comments, looks like:
package ModPerl::EazyLife;
use ModPerl::MethodLookup ();
use Carp;
my @avail_modules = ModPerl::MethodLookup::avail_modules();
push @avail_modules, 'Apache'; # XXX: may go away
my $skip = qr|(::)?DESTROY$|;
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
if (@modules) {
eval "require $_" for @modules;
goto &$AUTOLOAD;
}
else {
return if $AUTOLOAD =~ /$skip/;
croak $hint || "Can't find $AUTOLOAD";
}
};
}
1;
You need to update your cvs and rebuild (because of the changes in the
autogenerated MethodLookup.pm 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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>>>
>>>
>>>>Boris Zentner wrote:
>>>
>>>[...]
>>>
>>>
>>>>>Right, but using Apache::Request is not so uncommon.
>>>>
>>>>May be A-R can be fixed to use a proper inheritance?
>>>
>>>Sorry I haven't been paying attention to this thread.
>>>If by "proper inheritance" you mean, A-R should require
>>>Apache::RequestRec when it's running inside mp2, then
>>>*that* can be fixed easily.
>>
>>Boris was talking about Apache-Request objects not working properly with
>>AUTOLOAD (i.e. the functions lookup isn't getting propagated to AUTOLOAD).
>>
>>A-R should load only classes that it needs and never more.
>
>
> In mp2, Apache::RequestRec *is the base class* for A-R (A-R shouldn't
> have any AUTOLOAD methods). AFAICT that certainly fits the bill as
> being a necessity. How can a subclass be expected to work properly if
> its parent modules aren't available?
That's the thing we are trying to solve. You get $r (Apache::RequestRec
object), but none of the classes is loaded for you (because there are many
sub-packages that load parts of the API you can call on $r). So we are trying
the solution of defining Apache::RequestRec::AUTOLOAD which will resolve the
methods to modules containing them and load the modules behind the scenes as
they are needed. This is similar to AutoLoader but here we deal with XS modules.
So let's say you do:
sub handler {
my $r = shift;
$r->content_type('foo/bar');
w/o explicitly loading Apache::RequestRec. content_type will make its way to
Apache::RequestRec::AUTOLOAD, which will figure out that the method lives in
the Apache::RequestRec module and load it for you. Of couse if you preloaded
the module, everything will work w/o going through AUTOLOAD.
Now if $apr (Apache::Request object) is a sub-class of Apache::RequestRec and
the Apache::RequestRec module wasn't loaded so far. Calling
$apr->content_type('foo/bar');
should try to find Apache::Request::AUTOLOAD and since there is none, go up
@ISA and find Apache::RequestRec::AUTOLOAD, which will resolve the lookup and
load the missing module accomplishing the call.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Stefan Traby <st...@hello-penguin.com>.
On Fri, Feb 13, 2004 at 04:38:21PM -0500, Joe Schaefer wrote:
> In mp2, Apache::RequestRec *is the base class* for A-R (A-R shouldn't
> have any AUTOLOAD methods). AFAICT that certainly fits the bill as
> being a necessity. How can a subclass be expected to work properly if
> its parent modules aren't available?
Are you talking about the use-chain that is required?
I run happy with this: (If I got you wrong, sorry)
if (!defined $PApp::Apache2::_compiled) { eval do { local $/; <DATA> }; die if $@ } 1;
__DATA__
#line 5 "(PApp/Apache2.pm)"
package PApp::Apache2::Gateway;
use Apache2 ();
use Apache::Log ();
use Apache::RequestIO ();
use Apache::RequestRec ();
our @ISA = Apache::RequestRec::;
sub new {
bless $_[1], $_[0];
}
--
ciao -
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> >>Boris Zentner wrote:
> > [...]
> >
> >>>Right, but using Apache::Request is not so uncommon.
> >>
> >>May be A-R can be fixed to use a proper inheritance?
> > Sorry I haven't been paying attention to this thread.
> > If by "proper inheritance" you mean, A-R should require
> > Apache::RequestRec when it's running inside mp2, then
> > *that* can be fixed easily.
>
> Boris was talking about Apache-Request objects not working properly with
> AUTOLOAD (i.e. the functions lookup isn't getting propagated to AUTOLOAD).
>
> A-R should load only classes that it needs and never more.
In mp2, Apache::RequestRec *is the base class* for A-R (A-R shouldn't
have any AUTOLOAD methods). AFAICT that certainly fits the bill as
being a necessity. How can a subclass be expected to work properly if
its parent modules aren't available?
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Boris Zentner wrote:
>
>
> [...]
>
>
>>>Right, but using Apache::Request is not so uncommon.
>>
>>May be A-R can be fixed to use a proper inheritance?
>
>
> Sorry I haven't been paying attention to this thread.
> If by "proper inheritance" you mean, A-R should require
> Apache::RequestRec when it's running inside mp2, then
> *that* can be fixed easily.
Boris was talking about Apache-Request objects not working properly with
AUTOLOAD (i.e. the functions lookup isn't getting propagated to AUTOLOAD).
A-R should load only classes that it needs and never more.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Boris Zentner wrote:
[...]
> > Right, but using Apache::Request is not so uncommon.
>
> May be A-R can be fixed to use a proper inheritance?
Sorry I haven't been paying attention to this thread.
If by "proper inheritance" you mean, A-R should require
Apache::RequestRec when it's running inside mp2, then
*that* can be fixed easily.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Freitag, 13. Februar 2004 04:17 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>
>
> [...]
>
>
>>> 2. EazyLife can not know about my methods, so the option is guess and
>>>load all classes with methods that may satisfy me or ignore me. I dislike
>>>both and Apache::Request forwards everything unknown to the environ
>>>object, but it seems it looks what the object can ( untested ) so nothing
>>>is forwarded until the class is loaded.
>>
>>Well, may be your case is much more complicated than the average case, and
>>EazyLife could benefit a majority of users. And someone like you will have
>>to manually figure out which modules to load. Unless you have better idea.
>
>
> Right, but using Apache::Request is not so uncommon.
May be A-R can be fixed to use a proper inheritance?
> If the methods and functions are grouped in the classfiles then
> ModPerl::MethodLookup, EazyLife and a lot of hazzle including inherence work
> out of the box. Just to remark this a last time.
Yes, I remember that ;)
> I change the handle part a little
>
> # handle inheritance
> if (!@modules && $_[0] && ref( $_[0] ) ) {
> my($hint, @super_classes) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD);
> for (@super_classes) {
> push @modules, $_ if $_[0]->isa($_);
> }
Ooops, of course it's $_[0] and not $AUTOLOAD that's the object ;) Thanks for
the fix.
> But even then, it will not work. print seems a good startingpoint. Again from
> my example:
>
> lookup_method find some possible superclasses for SuperRequestRec.
>
> Apache::Filter and
> Apache::RequestIO.
>
> But the superclass for SuperRequestRec is Apache::RequestRec.
Ah, right. We are after the second argument (Apache::RequestRec), not the
first one (Apache::RequestIO).
I'll get back to you with a proper implementation.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Freitag, 13. Februar 2004 04:17 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >
> > 2. EazyLife can not know about my methods, so the option is guess and
> > load all classes with methods that may satisfy me or ignore me. I dislike
> > both and Apache::Request forwards everything unknown to the environ
> > object, but it seems it looks what the object can ( untested ) so nothing
> > is forwarded until the class is loaded.
>
> Well, may be your case is much more complicated than the average case, and
> EazyLife could benefit a majority of users. And someone like you will have
> to manually figure out which modules to load. Unless you have better idea.
Right, but using Apache::Request is not so uncommon.
If the methods and functions are grouped in the classfiles then
ModPerl::MethodLookup, EazyLife and a lot of hazzle including inherence work
out of the box. Just to remark this a last time.
>
> > Back to EazyLife:
> > It calls the AUTOLOAD function and in my case it is the right one. But if
> > My class is a new one ( one that is not part of mod_perl ) then
> > ModPerl::MethodLookup simply find nothing and dies.
> >
> > suppose this ( untested and useless ) example:
> >
> > package SuperRequestRec;
> > our @ISA = qw!Apache::RequestRec!;
> > sub new {
> > my $class = shift;
> > return bless shift, $class;
> > }
> > 1;
> >
> > sub handler :method {
> > my ( $c, $r ) = @_;
> > my $sr = SuperRequestRec->new( $r );
> > $sr->print("Hi");
> > return DONE;
> > }
> >
> > see this line from EazyLife.pm
> >
> > ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
> >
> > $AUTOLOAD may be SuperRequestRec::print
> >
> > and $_[0] is a reference to SuperRequestRec.
>
> I see what you mean. Try to patch it to try first:
>
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
> and if it fails:
>
> ModPerl::MethodLookup::lookup_method($AUTOLOAD);
>
> The second argument (@_) is optional to help resolve the situation when
> there is more than one class with the same method. For example:
>
> % perl -MApache2 -MModPerl::MethodLookup -e print_method new
> There is more than one class with method 'new'
> try one of:
> use APR::NetLib ();
> use APR::UUID ();
> use APR::Bucket ();
> use APR::Pool ();
> use Apache::RequestUtil ();
> use APR::ThreadMutex ();
> use APR::Brigade ();
> %
> % perl -MApache2 -MModPerl::MethodLookup -e print_method new
> Apache::RequestRec
>
> To use method 'new' add:
> use Apache::RequestUtil ();
>
> So how about this (it's untested):
>
> ----------------------------------
> package EazyLife;
>
> use ModPerl::MethodLookup ();
>
> for my $module (ModPerl::MethodLookup::avail_modules()) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> # handle inheritance
> unless (@modules) {
> my($hint, @super_classes) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD);
> for (@super_classes) {
> push @modules, $_ if ref($AUTOLOAD) && $AUTOLOAD->isa($_);
> }
> }
I change the handle part a little
# handle inheritance
if (!@modules && $_[0] && ref( $_[0] ) ) {
my($hint, @super_classes) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD);
for (@super_classes) {
push @modules, $_ if $_[0]->isa($_);
}
But even then, it will not work. print seems a good startingpoint. Again from
my example:
lookup_method find some possible superclasses for SuperRequestRec.
Apache::Filter and
Apache::RequestIO.
But the superclass for SuperRequestRec is Apache::RequestRec.
>
> if (@modules) {
> eval "require $_" for @modules;
> goto &$AUTOLOAD;
> }
> else {
> die $hint;
> }
> };
> }
>
> 1;
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Donnerstag, 12. Februar 2004 18:49 schrieb Stas Bekman:
>
>>>The biggest drawback for me is whenever inherence comes into play it wont
>>>work. Method_lookup is a hack. It is nice to have, but it whould much
>>>better if it is not needed at all.
>>
>>Do you suggest that AUTOLOAD doesn't work with inheritance? Doesn't it call
>>the right AUTOLOAD function?
>
>
> Yes, AUTOLOAD has some drawbacks. During my testing I found two of them
> imediately.
>
> 1. You can not rely on ->can. If I have a object and ask $obj->can('print')
> The answer is yes it can print, or I do not know maybe we can load print try
> it! Thats odd. But not a mod_perl issue.
>
> 2. EazyLife can not know about my methods, so the option is guess and load
> all classes with methods that may satisfy me or ignore me. I dislike both and
> Apache::Request forwards everything unknown to the environ object, but it
> seems it looks what the object can ( untested ) so nothing is forwarded until
> the class is loaded.
Well, may be your case is much more complicated than the average case, and
EazyLife could benefit a majority of users. And someone like you will have to
manually figure out which modules to load. Unless you have better idea.
> Back to EazyLife:
> It calls the AUTOLOAD function and in my case it is the right one. But if My
> class is a new one ( one that is not part of mod_perl ) then
> ModPerl::MethodLookup simply find nothing and dies.
>
> suppose this ( untested and useless ) example:
>
> package SuperRequestRec;
> our @ISA = qw!Apache::RequestRec!;
> sub new {
> my $class = shift;
> return bless shift, $class;
> }
> 1;
>
> sub handler :method {
> my ( $c, $r ) = @_;
> my $sr = SuperRequestRec->new( $r );
> $sr->print("Hi");
> return DONE;
> }
>
> see this line from EazyLife.pm
>
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> $AUTOLOAD may be SuperRequestRec::print
>
> and $_[0] is a reference to SuperRequestRec.
I see what you mean. Try to patch it to try first:
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
and if it fails:
ModPerl::MethodLookup::lookup_method($AUTOLOAD);
The second argument (@_) is optional to help resolve the situation when there
is more than one class with the same method. For example:
% perl -MApache2 -MModPerl::MethodLookup -e print_method new
There is more than one class with method 'new'
try one of:
use APR::NetLib ();
use APR::UUID ();
use APR::Bucket ();
use APR::Pool ();
use Apache::RequestUtil ();
use APR::ThreadMutex ();
use APR::Brigade ();
%
% perl -MApache2 -MModPerl::MethodLookup -e print_method new Apache::RequestRec
To use method 'new' add:
use Apache::RequestUtil ();
So how about this (it's untested):
----------------------------------
package EazyLife;
use ModPerl::MethodLookup ();
for my $module (ModPerl::MethodLookup::avail_modules()) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
# handle inheritance
unless (@modules) {
my($hint, @super_classes) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD);
for (@super_classes) {
push @modules, $_ if ref($AUTOLOAD) && $AUTOLOAD->isa($_);
}
}
if (@modules) {
eval "require $_" for @modules;
goto &$AUTOLOAD;
}
else {
die $hint;
}
};
}
1;
----------------------------------
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Donnerstag, 12. Februar 2004 18:49 schrieb Stas Bekman:
> > The biggest drawback for me is whenever inherence comes into play it wont
> > work. Method_lookup is a hack. It is nice to have, but it whould much
> > better if it is not needed at all.
>
> Do you suggest that AUTOLOAD doesn't work with inheritance? Doesn't it call
> the right AUTOLOAD function?
Yes, AUTOLOAD has some drawbacks. During my testing I found two of them
imediately.
1. You can not rely on ->can. If I have a object and ask $obj->can('print')
The answer is yes it can print, or I do not know maybe we can load print try
it! Thats odd. But not a mod_perl issue.
2. EazyLife can not know about my methods, so the option is guess and load
all classes with methods that may satisfy me or ignore me. I dislike both and
Apache::Request forwards everything unknown to the environ object, but it
seems it looks what the object can ( untested ) so nothing is forwarded until
the class is loaded.
Back to EazyLife:
It calls the AUTOLOAD function and in my case it is the right one. But if My
class is a new one ( one that is not part of mod_perl ) then
ModPerl::MethodLookup simply find nothing and dies.
suppose this ( untested and useless ) example:
package SuperRequestRec;
our @ISA = qw!Apache::RequestRec!;
sub new {
my $class = shift;
return bless shift, $class;
}
1;
sub handler :method {
my ( $c, $r ) = @_;
my $sr = SuperRequestRec->new( $r );
$sr->print("Hi");
return DONE;
}
see this line from EazyLife.pm
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
$AUTOLOAD may be SuperRequestRec::print
and $_[0] is a reference to SuperRequestRec.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Mittwoch, 11. Februar 2004 02:16 schrieb Stas Bekman:
>
>>>So I think Apache::Request use a kind of ->can to check for a method
>>>before it forwards it. This makes the EazyLife option useless for me. (
>>>Or I have to support a kind of autoloader or preloader for my class, but
>>>that make it useless too. )
>>
>>I think not. headers_in called on $r should have AUTOLOADED
>>Apache::RequestRec. Now since you call it on Apache::Request::PageKit for
>>some reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably
>>a problem in either Apache::Request::PageKit or Apache::Request, with
>>inheritance gone wrong.
>>
>>Does it work for you if you use a pure modperl handler/registry script?
>
>
> Yes, it works. But it turns out to be _very_ terrible in my case. I vote for
> removing the EazyLife patch or make it a config option ( in httpd.conf ).
> Perhaps there are better solutions.
>
> I encount zilions of ::DESTROY searches. But I can not install a ::DESTROY sub
> for every module, it may have it's own one.
That can be handled. As in:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
> The biggest drawback for me is whenever inherence comes into play it wont
> work. Method_lookup is a hack. It is nice to have, but it whould much better
> if it is not needed at all.
Do you suggest that AUTOLOAD doesn't work with inheritance? Doesn't it call
the right AUTOLOAD function?
> The end of my testing was that I was forced to add a AUTOLOAD method for my
> class that fakes my environment and make a call to the RequestRec object to
> make it work.
>
> The die statement in EasyLife.pm should include $AUTOLOAD and @_ for
> debugging, since $hint was most of the time ''.
Sure, that can be handled too.
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Mittwoch, 11. Februar 2004 02:16 schrieb Stas Bekman:
> > So I think Apache::Request use a kind of ->can to check for a method
> > before it forwards it. This makes the EazyLife option useless for me. (
> > Or I have to support a kind of autoloader or preloader for my class, but
> > that make it useless too. )
>
> I think not. headers_in called on $r should have AUTOLOADED
> Apache::RequestRec. Now since you call it on Apache::Request::PageKit for
> some reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably
> a problem in either Apache::Request::PageKit or Apache::Request, with
> inheritance gone wrong.
>
> Does it work for you if you use a pure modperl handler/registry script?
Yes, it works. But it turns out to be _very_ terrible in my case. I vote for
removing the EazyLife patch or make it a config option ( in httpd.conf ).
Perhaps there are better solutions.
I encount zilions of ::DESTROY searches. But I can not install a ::DESTROY sub
for every module, it may have it's own one.
The biggest drawback for me is whenever inherence comes into play it wont
work. Method_lookup is a hack. It is nice to have, but it whould much better
if it is not needed at all.
The end of my testing was that I was forced to add a AUTOLOAD method for my
class that fakes my environment and make a call to the RequestRec object to
make it work.
The die statement in EasyLife.pm should include $AUTOLOAD and @_ for
debugging, since $hint was most of the time ''.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> I tried it and unfortunely it did not work for me. I downloaded the CVS
> version of modperl-2 and installed your patch.
Thanks for testing it, Boris.
> As next step I removed all MP2 use directives.
>
> #use Apache::RequestRec ();
> #use Apache::RequestIO ();
> #use Apache::ServerUtil ();
> #use Apache::RequestUtil ();
> #use Apache::Util ();
> #use APR::Date ();
>
> This is the result.
>
> waiting 60 seconds for server to start: ..[Tue Feb 10 17:57:49 2004] [warn]
> Syntax error
> at /home/ptest2/src/Apache-PageKit-2.12-5/t/conf/extra.last.conf:15 Can't
> locate object method "server" via package "Apache"
> at /home/ptest2/src/Apache-PageKit-2.12-5/blib/lib/Apache/PageKit.pm line
> 113.
>
> Now I uncomment
>
> use Apache::ServerUtil ();
>
> to get access to the server method.
EazyLife works for objects $r, $s, etc. I don't remember we have covered class
methods, but that is fixable. The reason the autoload didn't work here, is
that there is no Apache module, and therefore EazyLife didn't add
Apache::AUTOLOAD. Depending on the outcomings of the Apache:: namespace
extinction process, we may add it manually if it survives.
> Now my error message is
>
> Can't locate auto/Apache/Request/PageKit/headers_in.al
>
> So I think Apache::Request use a kind of ->can to check for a method before it
> forwards it. This makes the EazyLife option useless for me. ( Or I have to
> support a kind of autoloader or preloader for my class, but that make it
> useless too. )
I think not. headers_in called on $r should have AUTOLOADED
Apache::RequestRec. Now since you call it on Apache::Request::PageKit for some
reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably a
problem in either Apache::Request::PageKit or Apache::Request, with
inheritance gone wrong.
Does it work for you if you use a pure modperl handler/registry script?
--
__________________________________________________________________
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: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
I tried it and unfortunely it did not work for me. I downloaded the CVS
version of modperl-2 and installed your patch.
As next step I removed all MP2 use directives.
#use Apache::RequestRec ();
#use Apache::RequestIO ();
#use Apache::ServerUtil ();
#use Apache::RequestUtil ();
#use Apache::Util ();
#use APR::Date ();
This is the result.
waiting 60 seconds for server to start: ..[Tue Feb 10 17:57:49 2004] [warn]
Syntax error
at /home/ptest2/src/Apache-PageKit-2.12-5/t/conf/extra.last.conf:15 Can't
locate object method "server" via package "Apache"
at /home/ptest2/src/Apache-PageKit-2.12-5/blib/lib/Apache/PageKit.pm line
113.
Now I uncomment
use Apache::ServerUtil ();
to get access to the server method.
Now my error message is
Can't locate auto/Apache/Request/PageKit/headers_in.al
So I think Apache::Request use a kind of ->can to check for a method before it
forwards it. This makes the EazyLife option useless for me. ( Or I have to
support a kind of autoloader or preloader for my class, but that make it
useless too. )
Am Montag, 9. Februar 2004 19:38 schrieb Stas Bekman:
> Stas Bekman wrote:
> > Perrin Harkins wrote:
> >> On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
> >>> I now more or less have an idea on how to solve the code usage problem.
> >>
> >> Great!
> >
> > My idea is replace UNIVERSAL::AUTOLOAD with AUTOLOAD for each class that
> > contains objects, so when the method is called on that object it'll do
> > just that:
> > http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
>
> [...]
>
> OK, here it is. Please give it a try:
>
> Index: lib/ModPerl/WrapXS.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
> retrieving revision 1.64
> diff -u -u -r1.64 WrapXS.pm
> --- lib/ModPerl/WrapXS.pm 31 Jan 2004 10:06:59 -0000 1.64
> +++ lib/ModPerl/WrapXS.pm 9 Feb 2004 18:36:02 -0000
> @@ -786,6 +786,16 @@
> return keys %$methods;
> }
>
> +sub avail_modules {
> + my %modules = ();
> + for my $method (keys %$methods) {
> + for my $item ( @{ $methods->{$method} }) {
> + $modules{$item->[MODULE]}++;
> + }
> + }
> + return keys %modules;
> +}
> +
> sub preload_all_modules {
> _get_modules() unless $modules;
> eval "require $_" for keys %$modules;
> Index: src/modules/perl/mod_perl.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
> retrieving revision 1.206
> diff -u -u -r1.206 mod_perl.c
> --- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
> +++ src/modules/perl/mod_perl.c 9 Feb 2004 18:36:02 -0000
> @@ -246,6 +246,10 @@
> av_push(GvAV(PL_incgv),
> newSVpv(ap_server_root_relative(p, "lib/perl"), 0));
> #endif /* MP_COMPAT_1X */
> +
> + /* AUTOLOADs */
> + /* XXX: consider adding a config flag not to preload this module */
> + modperl_require_module(aTHX_ "ModPerl::EazyLife", TRUE);
>
> if (!modperl_config_apply_PerlRequire(s, scfg, perl, p)) {
> exit(1);
> --- /dev/null 1969-12-31 16:00:00.000000000 -0800
> +++ lib/ModPerl/EazyLife.pm 2004-02-03 08:00:34.000000000 -0800
> @@ -0,0 +1,19 @@
> +package EazyLife;
> +
> +use ModPerl::MethodLookup ();
> +
> +for my $module (ModPerl::MethodLookup::avail_modules()) {
> + *{"$module\::AUTOLOAD"} = sub {
> + my($hint, @modules) =
> + ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
> + if (@modules) {
> + eval "require $_" for @modules;
> + goto &$AUTOLOAD;
> + }
> + else {
> + die $hint;
> + }
> + };
> +}
> +
> +1;
>
>
> ______________________________________________________________
> 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
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org