Re: method handlers and push_handlers / set_handlers
Stas Bekman wrote:
Tim Noll wrote:
Is there a proper way to call a method handler using either
push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the
handler in
an anonymous sub is a workaround, but I was wondering if there was a
better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
See
http://perl.apache.org/guide/config.html#Perl_Method_Handlers, the eagle
and cookbook books.
PERL_METHOD_HANDLERS=1 + $$ prototype for Apache::Test::handler
My question was really about the proper way to call method handlers from
either push_handlers or set_handlers since the normal technique (first
example above) calls them as normal subs, i.e. the first parameter is not
the class name. The second example, however, seems to do the trick. I just
wanted to know whether there was a better technique and/or any pitfalls to
this technique. While searching around the web a bit more today, I came
across the example below from the mod_perl_method_handlers man page, which
seems to be similar, so I guess I'm on the right track. However, any
comments would still be appreciated.
snip
$r-push_handlers(PerlHandler =
sub {
my $r = shift;
$self-perl_handler_method($r);
}
);
/snip
-Tim
Re: method handlers and push_handlers / set_handlers
My question was really about the proper way to call method handlers from
either push_handlers or set_handlers since the normal technique (first
example above) calls them as normal subs, i.e. the first parameter is not
the class name. The second example, however, seems to do the trick. I just
wanted to know whether there was a better technique and/or any pitfalls to
this technique. While searching around the web a bit more today, I came
across the example below from the mod_perl_method_handlers man page, which
seems to be similar, so I guess I'm on the right track. However, any
comments would still be appreciated.
snip
$r-push_handlers(PerlHandler =
sub {
my $r = shift;
$self-perl_handler_method($r);
}
);
/snip
you need to push the handler by name
$r-push_handlers(PerlHandler = 'My::Handler');
at least until this patch makes it into mod_perl core...
http://marc.theaimsgroup.com/?l=apache-modperl-devm=101164617829467w=2
(though I forgot what the patch was for :)
at any rate, see the latter part of recipe 10.3 :)
--Geoff
method handlers and push_handlers / set_handlers
Is there a proper way to call a method handler using either push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the handler in
an anonymous sub is a workaround, but I was wondering if there was a better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
-Tim
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
Is there a proper way to call a method handler using either push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the handler in
an anonymous sub is a workaround, but I was wondering if there was a better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
-Tim
See
http://perl.apache.org/guide/config.html#Perl_Method_Handlers, the eagle
and cookbook books.
PERL_METHOD_HANDLERS=1 + $$ prototype for Apache::Test::handler
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
OK, in answer to my own question, after embedding debug statements all over
my code, I found the source of my problem: After finally moving this project
from Win2K to Debian, I neglected to update the driver string in
DBI-connect. How embarassing ... :-(
In any case, this still leaves the question: Why was there no line number or
back trace in the error log?
-Tim
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
OK, in answer to my own question, after embedding debug statements all over
my code, I found the source of my problem: After finally moving this project
from Win2K to Debian, I neglected to update the driver string in
DBI-connect. How embarassing ... :-(
In any case, this still leaves the question: Why was there no line number or
back trace in the error log?
I guess because any code can disable your setting locally or globally by
overriding $SIG{__WARN__} using local() or without it after you've
defined it. Or simply turning warnings off locally or again globally
(horrors).
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
push_handlers, set_handlers
Apache 1.3.22 mod_perl 1.26 I have noticed some strange behavior when attempting to stack handlers below the 'ChildInit' phase. This code executes fine when placed in a server initialization script: Apache-push_handlers( PerlChildInitHandler= \My::Child::handler ); When using the code below in a server initialization script without any apache config directives the handler does not get called. Apache-push_handlers( PerlHandler= \My::handler ); When applying the following apache conf directive the handler seems to only get called occasionally (initialization of child process?). Files *.html SetHandler perl-script /Files Although, when using the 'push_handlers' method at another part of the request phase the handler gets called occasionally. Apache-push_handlers( PerlFixupHandler= \My::Other::handler ); When using the method below the handlers do not get called at all. Apache-httpd_conf(EOF); Files *.html PerlHandler My::handler SetHandler perl-script /Files EOF Apache-httpd_conf(EOF); PerlFixupHandler My::Other::handler EOF Of course when setting the directives into the apache conf all seems to work well. PerlFixupHandler My::Other Files *.html PerlHandler My SetHandler perl-script /Files Any ideas as to why this strange behavior? When trying to use the 'set_handlers' method it blows up stating the request object is not created. I cannot see the reason why the request object should be needed to set/push handlers which are used to 'handle' the request phases. Thanks,
