>
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.
No, the critical line is:
return HTTP_INTERNAL_SERVER_ERROR;
which results in error logging, up the calling tree.
at modperl_callback_run_handlers:192
status = modperl_callback(aTHX_ handlers[i], p, r, s, av_args);
MP_TRACE_h(MP_FUNC, "%s returned %d\n", handlers[i]->name, status);
if ((status != OK) && (status != DECLINED)) {
status = modperl_errsv(aTHX_ status, r, s);in other words, grep for modperl_errsv.
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.
I believe what you have to do is what I've pasted just above. Get the return code and run modperl_errsv if the status is not OK/DECLINED. Does this work for you?
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.
I'll add a test for that and if that's the case, will be fixed.
Thanks Geoff.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
