RE: [mp2] apache/mod_perl starup failure using cvs 09
Hi Stas -
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2003 10:45 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
>
>
> Beau E. Cox wrote:
> > 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).
>
> since 09 > 08, it *is* a change in behaviour between mp1 and mp2
> ;) though
> potentially not the final one.
>
> > I will continue using mp2-08 and talk to the mason
>
> meanwhile you can continue using the lates cvs, but add to the
> beginning of
> your startup to cheat on the latest change:
>
> require Apache::RequestUtil;
> no warnings 'redefine';
> my $sub = *Apache::request{CODE};
> *Apache::request = sub {
> my $r;
> eval { $r = $sub->('Apache'); };
> # warn $@ if $@;
> return $r;
> };
>
> > 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.
>
> You mean Apache::Request?
Yes...
> [...]
Your fix works perfectly - I'm a happy camper. I passed our discussion
to the mason list - will keep you folks informed.
Aloha => Beau;
PS: Have you ever noticed the closer your deadline becomes, the more
things go wrong and the more mistakes you make?
Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
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).
since 09 > 08, it *is* a change in behaviour between mp1 and mp2 ;) though
potentially not the final one.
I will continue using mp2-08 and talk to the mason
meanwhile you can continue using the lates cvs, but add to the beginning of
your startup to cheat on the latest change:
require Apache::RequestUtil;
no warnings 'redefine';
my $sub = *Apache::request{CODE};
*Apache::request = sub {
my $r;
eval { $r = $sub->('Apache'); };
# warn $@ if $@;
return $r;
};
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.
You mean Apache::Request?
My only concern is that mp2 and mason will eventually work well
together - I feel a little like I am caught in the middle ;)
if you don't mind to get frustrated here and there, that's the best position
to learn things ;)
Please don't spend any more time on this until I get a mason answer.
;)
__
Stas BekmanJAm_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
RE: [mp2] apache/mod_perl starup failure using cvs 09
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> 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 BekmanJAm_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
>
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;
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.
[...]
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 BekmanJAm_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
RE: [mp2] apache/mod_perl starup failure using cvs 09
Hi Stas -
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2003 6:18 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
>
>
> Beau E. Cox wrote:
> > -8<-- Start Bug Report 8<--
> > 1. Problem Description:
> >
> > Sorry - is this mason's problem?
> >
> > Apache does not start using latest mod_perl2 (cvs) when
> > using a mason startup script.
> >
> > Failure matrix:
> >
> > mod_perl version mason version using startup.pl using
> simple-mason.pl
> > OK?
> >
> --
> >
> > 08-source 1.16 yes yes
> > OK
> > 08-source 1.19 yes yes
> > OK
> > 09-cvs 1.19 yes yes
> > FAIL
> > 09-cvs 1.16 yes yes
> > FAIL
> > 09-cvs 1.19 no-in httpd no mason
> > OK
> > 09-cvs 1.19 no-in httpd no-in httpd
> > OK
> >
> > Apache startup console output:
> >
> > [Tue Mar 04 16:45:09 2003] [error] Global $r object is not
> available. Set:
> > PerlOptions +GlobalRequest
> > in httpd.conf at
> /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
> > line 573.
> > Compilation failed in require at (eval 3) line 1.
>
> [...]
>
> > HTML::Mason::ApacheHandler revelant lines:
> >
> > my $allowed_params = $class->allowed_params(%defaults, %params);
> >
> > 573: if ( exists $allowed_params->{comp_root} and
> > my $req = $r || Apache->request ) # DocumentRoot is only
> available
>
> 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.
>
> __
> Stas BekmanJAm_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
>
>
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.
Aloha => Beau;
Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using simple-mason.pl
OK?
--
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[...]
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class->allowed_params(%defaults, %params);
573: if ( exists $allowed_params->{comp_root} and
my $req = $r || Apache->request ) # DocumentRoot is only available
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.
__
Stas BekmanJAm_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
