perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: modperl_require_module failing silently
Date Tue, 27 May 2003 15:43:42 GMT

> Currently we have the following usages for modperl_mgv_resolve. Only
> modperl_handler_resolve is using false since the error is logged by itself.

if you by "logged by itself" this

 >             ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
 >                          "failed to resolve handler `%s'",
 >                          handler->name);

then what I'm after is more than that, specifically the ERRSV from this part 
of modperl_require_module

     if (SvTRUE(ERRSV)) {
         if (logfailure) {
             (void)modperl_errsv(aTHX_ HTTP_INTERNAL_SERVER_ERROR,
                                 NULL, NULL);
         return FALSE;

in other words, $@ - why it failed.

> However it does logs the failure reason, when resolved at run time. e.g. 
> break t/response/TestModperl/ and run t/TEST -v run
> What you are not telling me is what kid of callback you are having a 
> problem with. modperl_callback returns the status, which eventually 
> should propogate to Apache.

it's not that I'm having difficulty figuring out where the error is in the 
cycle - the callback is a normal handler and I'm doing normal things with 
it.  the issue is that you can't perl -cw mod_perl stuff, so I end up 
staring at the code for a very long time trying to find the missing 
semicolon or whatnot.  so, I guess the subject is a bit misleading - the 
silence was supposed to mean the lack of $@, not that things just aren't 
working :)

at any rate, if nobody else is having this issue, then I'm not going to 
worry about it since I'm issuing callbacks directly.  however, as pointed 
out below, I think it may be a larger issue for people who resolve handlers 
at runtime, in which case we probably need to fix it.  sorry I don't have 
the tuits right now to delve into all the scenarios properly.

> Can you trace where the error is lost? It 
> should work from XS code, no need to use PerlModule. If it doesn't we 
> need to fix it (without breaking other code ;)
> This is the usage of modperl_mgv_resolve:

>      modperl_handler_perl_get_handlers :
>      ---------------------
>             if (!modperl_mgv_resolve(aTHX_ handler, p, handler->name, 
> TRUE)) {
>                 MP_TRACE_h(MP_FUNC, "failed to resolve handler %s\n",
>                            handler->name);
>             }
> modperl_mgv.c:411:
>      modperl_hash_handlers
>      ---------------------
>      modperl_mgv_resolve(aTHX_ handler, p, handler->name, TRUE)

these two are the only places that will log $@, and they only happen at 
config time, not runtime, right?  this means that if I

$r->push_handlers(PerlFooHandler => "My::Module")

or something similar and My::Module hasn't been seen before, any 
compile-time failures won't be logged.

at least this is how I'm reading what is going on.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message