perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Beau E. Cox" <>
Subject RE: [mp2] apache/mod_perl starup failure using cvs 09
Date Wed, 05 Mar 2003 08:12:26 GMT

> -----Original Message-----
> From: Stas Bekman []
> Sent: Tuesday, March 04, 2003 9:23 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
> [...]
> >>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.
> [...]
> > 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
>     mod_perl Guide --->

Yea, Stas, I clearly see your reasoning. However, this is not a change
of behaviour between mp1 and mp2, but rather between mp2-08 and the
current cvs (09). I will continue using mp2-08 and talk to the mason
list - but it seems that folks over there are not too anxious to
do much in the line of mp2 development until the 'request' is converted.

My only concern is that mp2 and mason will eventually work well
together - I feel a little like I am caught in the middle ;)

Please don't spend any more time on this until I get a mason answer.

Aloha => Beau; 

View raw message