perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
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/env.pm 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.

--Geoff




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message