Discussion:
CAP::AutoRunmode not working with mod_perl again ??
(too old to reply)
Richard Jones
2008-11-07 13:44:40 UTC
Permalink
I know this was supposed to be fixed in v0.14 but it seems to be
happening again. In a trivial setup:

########################################
package My::CGIApp;

use base 'CGI::Application';
use CGI::Application::Plugin::AutoRunmode;

sub my_start_run_mode : StartRunmode {
my $self = shift;
return $self->dump_html;
}

sub mode2 : Runmode {
my $self = shift;
return $self->dump_html;
}

1;
#######################################

######################################################
[perl.conf]
PerlModule My::CGIApp
<location /cgiapp>
SetHandler perl-script
PerlResponseHandler "sub { My::CGIApp->new()->run(); return OK; }"
</location>

PerlModule ModPerl::Registry
Alias /perl/ /home/raj/perl/
<Location /perl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
#PerlOptions +ParseHeaders
#PerlOptions -GlobalRequest
Options +ExecCGI
</Location>
#######################################################

#######################################
# /home/raj/perl/cgiapp.pl:
use lib '/home/raj/myapp';

use My::CGIApp;
my $webapp = My::CGIApp->new();
$webapp->run();
#######################################

Request http://localhost/perl/cgiapp.pl (ie ModPerl::Registry) = "No
such run mode 'my_start_run_mode' at /home/raj/perl/cgiapp.pl line 7"

Request http://localhost/cgiapp (ie handler) = "No such run mode
'my_start_run_mode' at (eval 960) line 1"

So in both cases the system can load the target My::CGIApp module and
identify the StartRunmode, yet then declares 'no such runmode'!

What's really weird is that I can put CGIApp.pm in the same directory as
the registry instance script (cgiapp.pl) and re-point cgiapp.pl to the
new location and I get the $self->dump_html output, but it incorrectly
states Current Run-mode: 'start', and it cannot find
http://localhost/perl/cgiapp.pl?rm=mode2 (No such run mode 'mode2'), so
I don't think that's working properly either.

Previously I had an old app running fine as a mod_perl handler script
using CAP::AutoRunmode on a PCLinuxOS 2007 server, then re-built the
server with a different OS (Ubuntu 8.04), and straight away I got the
"no such runmode foo" error. So I assumed I had mis-configured mod_perl
and just switched over to mod_cgi and left it for a rainy day. It makes
me wonder whether something broke with a version change in some Perl
package, Apache2, mod_perl2, etc.

Currently using Apache/2.2.4 (Ubuntu) mod_fastcgi/2.4.2 mod_perl/2.0.2
Perl/v5.8.8. CGI::Application is v4.11 and CAP::AutoRunmode is v0.15. Is
this the same pre-0.14 mod_perl bug? It would be really useful if
someone can confirm they *do* have AutoRunmode working under
Apache2/mod_perl2, either as handler or registry, and if so how their
setup differs from mine.
--
Richard Jones

##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
Mark Stosberg
2008-11-09 03:04:14 UTC
Permalink
On Fri, 07 Nov 2008 13:44:40 +0000
Post by Richard Jones
I know this was supposed to be fixed in v0.14 but it seems to be
That sounds frustrating Richard. I haven't gone back to use AutoRunmode after
getting bitten the first time around with the mod_perl issue. Have you tried
the RunmodeDeclare plugin as an alternative?

http://search.cpan.org/perldoc?CGI::Application::Plugin::RunmodeDeclare

Mark



##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
Richard Jones
2008-11-09 16:12:42 UTC
Permalink
Post by Mark Stosberg
On Fri, 07 Nov 2008 13:44:40 +0000
Post by Richard Jones
I know this was supposed to be fixed in v0.14 but it seems to be
That sounds frustrating Richard. I haven't gone back to use AutoRunmode after
getting bitten the first time around with the mod_perl issue. Have you tried
the RunmodeDeclare plugin as an alternative?
Hi Mark,

Yes I have - and it does now seem to work OK under all 3 envs (mod_perl,
HTTP::Simple::Server/CA::Server & mod_cgi), but I'm still a little wary
of it as it seems to use deeper magic than AutoRunmode, and I'm not sure
all the issues that were discussed earlier [RFC: declarative run modes
(inspired by Method::Signatures)] have been addressed. Is RunmodeDeclare
'safe' to use in production in combination with many other plugins (eg
CAP::Authentication, CAP::Authorization, etc) yet?

The choice actually is a) fix AutoRunmode - preferable as my app. is
already working with it (except under mod_perl); b) switch to
RunmodeDeclare, where I will have a lot of code to convert and is pretty
much a one-way ticket; and c) revert to the traditional method of
declaring $self->run_modes & $self->start_mode in setup(), which can
probably be considered the safer option.
--
Richard Jones

##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
Rhesa Rozendaal
2008-11-09 19:23:51 UTC
Permalink
Post by Richard Jones
Post by Mark Stosberg
On Fri, 07 Nov 2008 13:44:40 +0000
Post by Richard Jones
I know this was supposed to be fixed in v0.14 but it seems to be
That sounds frustrating Richard. I haven't gone back to use AutoRunmode after
getting bitten the first time around with the mod_perl issue. Have you tried
the RunmodeDeclare plugin as an alternative?
Hi Mark,
Yes I have - and it does now seem to work OK under all 3 envs (mod_perl,
HTTP::Simple::Server/CA::Server & mod_cgi), but I'm still a little wary
of it as it seems to use deeper magic than AutoRunmode, and I'm not sure
all the issues that were discussed earlier [RFC: declarative run modes
(inspired by Method::Signatures)] have been addressed. Is RunmodeDeclare
'safe' to use in production in combination with many other plugins (eg
CAP::Authentication, CAP::Authorization, etc) yet?
As far as I know, we fixed all the issues mentioned in that thread. I've been
using RunmodeDeclare in production for a couple of weeks now, and it works
fine. Since we have quite a few customers running their (online) business on
our software, I tend to be careful with what I put into production. And I'm
quite comfortable running it.

We use at least the following plugins in our apps:

CA::Dispatch
CAP::AutoRunmode
CAP::Session
CAP::Authentication
CAP::Authorization
Post by Richard Jones
The choice actually is a) fix AutoRunmode - preferable as my app. is
already working with it (except under mod_perl); b) switch to
RunmodeDeclare, where I will have a lot of code to convert and is pretty
much a one-way ticket; and c) revert to the traditional method of
declaring $self->run_modes & $self->start_mode in setup(), which can
probably be considered the safer option.
We use all three methods of registering run modes in our application: we
started out with the traditional way of calling "run_modes", "start_mode" and
"error_mode" in "setup". Later on, we adopted CAP::AutoRunmode for newer code,
and recently I've been moving us over to RunmodeDeclare in new cgiapp modules,
or when I have a need to refactor existing code. All three methods run happily
together. In fact, you could use all three in the same module, but I wouldn't
recommend that from a maintainability viewpoint.

HTH,
Rhesa

##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
Richard Jones
2008-11-10 13:37:15 UTC
Permalink
Post by Rhesa Rozendaal
Post by Richard Jones
On Fri, 07 Nov 2008 13:44:40 +0000 Richard Jones
Post by Richard Jones
I know this was supposed to be fixed in v0.14 but it seems to
That sounds frustrating Richard. I haven't gone back to use
AutoRunmode after getting bitten the first time around with the
mod_perl issue. Have you tried the RunmodeDeclare plugin as an
alternative?
Hi Mark,
Yes I have - and it does now seem to work OK under all 3 envs
(mod_perl, HTTP::Simple::Server/CA::Server & mod_cgi), but I'm
still a little wary of it as it seems to use deeper magic than
AutoRunmode, and I'm not sure all the issues that were discussed
earlier [RFC: declarative run modes (inspired by
Method::Signatures)] have been addressed. Is RunmodeDeclare 'safe'
to use in production in combination with many other plugins (eg
CAP::Authentication, CAP::Authorization, etc) yet?
As far as I know, we fixed all the issues mentioned in that thread.
I've been using RunmodeDeclare in production for a couple of weeks
now, and it works fine. Since we have quite a few customers running
their (online) business on our software, I tend to be careful with
what I put into production. And I'm quite comfortable running it.
OK, that's good to hear. So far on a small sub-set of my app it's
working fine, providing I *don't* mix run_mode declaration methods - see
below.
Post by Rhesa Rozendaal
CA::Dispatch
CAP::AutoRunmode
CAP::Session
CAP::Authentication
CAP::Authorization
I'm using a few more, and as far as I can tell so far they are all
working OK with RunmodeDeclare:

CGI::Application::Plugin::Forward
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::Session
CGI::Application::Plugin::ValidateRM
CGI::Application::Plugin::ConfigAuto
CGI::Application::Plugin::DBH
CGI::Application::Plugin::TT
CGI::Application::Plugin::Stash
CGI::Application::Plugin::Authentication
CGI::Application::Plugin::Authorization
CGI::Application::Plugin::LogDispatch
Post by Rhesa Rozendaal
Post by Richard Jones
The choice actually is a) fix AutoRunmode - preferable as my app.
is already working with it (except under mod_perl); b) switch to
RunmodeDeclare, where I will have a lot of code to convert and is
pretty much a one-way ticket; and c) revert to the traditional
method of declaring $self->run_modes & $self->start_mode in
setup(), which can probably be considered the safer option.
we started out with the traditional way of calling "run_modes",
"start_mode" and "error_mode" in "setup". Later on, we adopted
CAP::AutoRunmode for newer code, and recently I've been moving us
over to RunmodeDeclare in new cgiapp modules, or when I have a need
to refactor existing code. All three methods run happily together. In
fact, you could use all three in the same module, but I wouldn't
recommend that from a maintainability viewpoint.
Well, I tried it with RunmodeDeclare in a sub-class that inherits from a
super-class that uses AutoRunmode methods, and it bombed trying to load
the super-class startmode template (menu.tt) in the sub-class startmode
template path - ie should have loaded /admin/user/function/default.tt,
but tried to load /admin/user/function/menu.tt, which is the superclass
default template in /admin/menu.tt. But as I mentioned above, providing
I use RunmodeDeclare throughout, it seems fine. It's probably also OK to
mix-n-match, within an app, providing it's not in a subclass/superclass
pair.
--
Richard Jones

##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################

Mark Stosberg
2008-11-09 20:08:47 UTC
Permalink
Post by Richard Jones
The choice actually is a) fix AutoRunmode - preferable as my app. is
already working with it (except under mod_perl); b) switch to
RunmodeDeclare, where I will have a lot of code to convert and is pretty
much a one-way ticket; and c) revert to the traditional method of
declaring $self->run_modes & $self->start_mode in setup(), which can
probably be considered the safer option.
I see the big picture decision here as being about efficiency. Which
saves the most time in the end? I thought AutoRunmode would, because it
made the code more concise, but I lost that bit a big way because of the
time I spent tracking down a related mod_perl bug and undoing the code.

RunmodeDeclare would have similar trade-offs: If there aren't any
serious current or future bugs, then it's a win. If you hit one,
you lose.

Currently, I've using traditional approach. It's not not the most
concise, but it's stable and reliable.

With my experience and yours, I feel unlikely to return to using
AutoRunmode again, but I'll consider RunmodeDeclare in the future, once
it's been proven in the wild longer.

Mark
--
http://mark.stosberg.com/blog




##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
Loading...