modperl_mgv_resolve has this magic where it tries to require a package,
and if it fails it tries to guess that the last segment of the package
name is really a function in the parent package so one can say:
PerlResponseHandler Apache::Foo::superhandler
and mod_perl will be smart enough to load Apache::Foo, after it has
failed to load Apache::Foo::superhandler, and find that function in there.
So far so good. Now consider the following example:
PerlResponseHandler Apache::Bar
It tries to resolve the handler, by first trying to
require('Apache/Bar.pm'). Now either because that file can't be found,
or because it has failed to compile, mod_perl 2.0 tries to be smart,
saying, hey let's load Apache.pm, and voila Apache.pm gets loaded. But
there is no sub BAR in Apache, so we give up and return 500, with
error_log saying:
[Fri Dec 06 20:03:56 2002] [error] failed to resolve handler `Apache::Bar'
where is the error generated when require('Apache/Bar.pm') has failed
you ask? It was lost because require('Apache.pm') was successful. And
the logic supresses the first error.
OK, this can be "sort of" resolved by keeping the first error around,
until we see whether we get what we wanted (CODE ref). And print the
original error if we don't.
What happends if require('Apache.pm') fails? According to the code we
should print the previous error, generated by require('Apache/Bar.pm').
But this can be the wrong error, if there was indeed sub Bar inside
Apache, and the loading of Apache.pm has failed because of...whatever.
in which case the second error should be printed. How do we guess which
is the right error? Printing both is a bad idea, as it's going to
generate extra traffic on the list...
Finally, the worst problem is this: what happens if there is sub Bar in
Apache.pm, require('Apache/Bar.pm') fails and require('Apache.pm')
succeeds and handler returns *success*, picking the wrong function. Oops.
IMHO, this guessing logic should be killed, and users should preload
explicitly the modules that they want to use if they specify a fully
qualified name.
__________________________________________________________________
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]
