jplindstrom has asked for the wisdom of the Perl Monks concerning the following question:

I tried to post to the Maypole mailing list, but <a href="http://maypole.perl.org/?MailingList">it seems to be down</a>

Weird thing. I just got Maypole working, almost, on top of an existing CDBI app. What's weird is that this works:

perl -I../lib -MMaypole::CLI=Boss::Opera::Maypole::App -e1 "http://loc +alhost/opera/op_operator/list"
But when I get that exact url in the browser I get a Not Found from Apache. I can get the front page at /opera/ (I use the factory templates), but not click on the op_operator link to list it.

The access log:

127.0.0.1 - - [15/Feb/2005:21:26:51 +0100] "GET /opera/op_operator/lis +t HTTP/1.1" 404 329

The error log:

[Tue Feb 15 21:26:51 2005] [error] [client 127.0.0.1] File does not ex +ist: C:/.../source/web/htdocs/opera, referer: http://localhost/opera/

Versions:

Maypole 2.09 (reinstalled to make sure it wasn't a stale version like +last time) Apache/2.0.48 (Win32)
This is my httpd.conf
PerlRequire "C:/.../source/web/startup.pl" <Location /opera> SetHandler perl-script PerlHandler Boss::Opera::Maypole::App </Location>

This is my Maypole application class:

package Boss::Opera::Maypole::App; use Maypole::Application; use File::Spec; use File::Basename; use Data::Dumper; use Carp qw/ cluck /; use Boss::Opera::Operator; use Boss::Opera::ProductGroup; sub debug { 1; } __PACKAGE__->config->model("Maypole::Model::CDBI::Plain"); __PACKAGE__->setup([qw/ Boss::Opera::Operator Boss::Opera::ProductGrou +p /]); __PACKAGE__->config->application_name('Boss Opera Configuration Databa +se'); __PACKAGE__->config->uri_base("http://localhost/opera/"); __PACKAGE__->config->template_root(File::Spec->rel2abs(dirname(__FILE_ +_) . "/../../../../web/htdocs/templates")); __PACKAGE__->config->rows_per_page(10); __PACKAGE__->config->display_tables([qw/ op_operator op_product_group +/]); Boss::Opera::Operator->untaint_columns( printable => [qw/name/], integ +er => [qw/gs_operator_id/] );

As a long-shot I also put this in my Maypole app class:

warn("new parse_path\n"); sub parse_path { my $self = shift; cluck(Dumper($self, \@_)); $self->SUPER::parse_path(@_); }

The first warning turns up in the Apache console window, but not the "cluck Dumper". Both are visible when running it from the CLI. None of this shows up in Apache even when I successfully get the front page, so...

I tried to insert warnings in Maypole::handler also, nothing shows in the log, ever. I also found a mention in the list archives of the exception method in connection to getting 404:s, I overrode that one too but nothing turns up in the error log.

*sigh*

What is going on here? Any ideas? What should I poke at next?

/J - sooo close

Replies are listed 'Best First'.
Re: Maypole::CLI works, but Apache says 404
by perrin (Chancellor) on Feb 16, 2005 at 14:01 UTC
    Your httpd.conf setup is only good for mod_perl 1.x. Using Maypole with mod_perl 2 doesn't seem to be documented, but I would suggest trying this:
    <Location /opera> SetHandler perl-script PerlResponseHandler Boss::Opera::Maypole::App </Location>
      Thanks, that worked also, but the old style didn't seem to be the problem.

      /J

Re: Maypole::CLI works, but Apache says 404 (solved, kinda)
by jplindstrom (Monsignor) on Feb 16, 2005 at 18:38 UTC
    Why the error:

    I managed to break the working BeerDB example by preloading my Maypole application class. If seems to work better if the class is loaded in each thread at first invocation. This works for setting the correct include lib with a PerlRequire in the httpd.conf:

    use File::Basename; use lib dirname(__FILE__); #use BeerDB; 1; __END__

    If I don't pre-load it, there is no output in the error log for warnings. Maybe this is the way Apache2 with threads is supposed to work. Maybe the threads in Apache2 + mod_perl 2 isn't very compatible yet. Maybe it's the usual caveats that go with using Perl threads. It make sense to have each thread keep it's own set of objects for everything, as similar to forking as possible.

    If this still would turn out to not work, it would be a bit of a downer becuase the nice promise of Apache2 was that it would work fine on Windows. It's not that I'd want to deploy it on Windows, but for development it would be convenient.

    Anyway, this messed up a lot of things, but I could not see at all what was wrong because I got the bogus 404 message.

    Why no error message:

    The root cause is that the TT process() doesn't work in my setup for some reason that broke with the threads thing (beer/list not found), and there is no way to see this, anywhere.

    Lots of debug output pinpointed this to the fact that View::Maypole::Base::error() thinks there can't be a template error if there are no $r->{objects}.

    # This is a rough test to see whether or not we're a template +or # a static page return -1 unless @{ $r->{objects} || [] };

    I'm not sure what's supposed to happen to not get a 404 if there are no objects, but that's what I get now. A 500 Internal Server Error would seem to be more appropriate, although perhaps uglier.

    /J

Re: Maypole::CLI works, but Apache says 404
by CountZero (Bishop) on Feb 16, 2005 at 21:20 UTC
    Are you sure Maypole now works on Apache2/mod_perl1.99?

    Sometime ago when I tried to install it on my Apache2/mod_perl1.99 I did not succeed and after searching far and wide I found out there are some serious problems to get it running on such a set-up. There were some recipes claiming to get it up on Apache2 but they did not work for me.

    Pity, as it seems very interesting.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      I'm not sure it works under load etc, but now at least it doesn't seem to crash and burn miserably :)

      I can very well imagine that the threads option shouldn't be used in production.

      /J

        Thanks, if not "when" :( I have some spare time, I will have a look at it again.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law