why does Mason needs $r at the server startup? There is no request object at the server startup, so it's only fair that mp reports the error.
[...]
Good point. However, I seemed to have given you the code of mason's ApacheHandler out of context; the snip above is from the 'new' method which I use in setting up the mason handler routine:
# Create ApacheHandler object at startup. my $ah = HTML::Mason::ApacheHandler->new ( args_method => "CGI", comp_root => "/srv/www/htdocs", data_dir => "/srv/www/mason", error_mode => 'output', );
In this trivial case it doesn't seem worthwhile to go to all that trouble, but, as in my production server, when working with a lot of (possible dynamic) vhosts, it works well.
If the Apache->request (or a request passed as the last - odd - parameter to new) is defined, some further processing occurs; but at startup, the request is neither expected to be there nor needed.
I guess (looking at my result matrix) that some change was made to mod_perl to prohibit even querying the presence of Apache->request at startup. So now I (and other mason folks) must find another way to instantiate handlers.
Would you have and suggestions from the mod_perl perspective? I will take this query over to mason if you feel that is where it belongs - but I'll need some further insight into the mod_perl changes.
I see what you mean. In mp1 you relied on Apache->request's not being defined as a side-effect to test whether you are inside request or not.
I will explain why I've chosen to croak, rather than return 'undef'.
In mp1 Apache->request was either undef (outside of request) or $r (during the request). You couldn't control that. In mp2 in order to optimize things, keeping the global request around is optional. So if you don't need it you get some speed improvement.
So if the user has the global request setting off and Apache->request returns undef, he may think that he is not inside the request phases (precisely what mason does), which is wrong.
Therefore if you still wish to rely on this (which is no longer always valid under mp2), you can do:
eval { $r = Apache->request}
to trap the croak.
may be you should use something else as a predicate to calling Apache->request. For example you could use:
ModPerl::Util::current_callback() to figure out where you are. Though it'll incur a checking of several options. So perhaps we need a new method or may be not. Ideas are welcome.
Philippe has agreed with my reasoning when I've suggested the change and nobody else has objected (or had any opinion at all), so it went in. Since nothing is cast is stone (yet) on the mp2 API, you may suggest your explanation why it should behave differently if you think that my idea is wrong.
__________________________________________________________________ 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
