Error.pm and RegistryCooker

I was forced to move from mod_perl to mod_perl2 because of Ubuntu. I had
originally created an Apache-Cocoon/Apache-AxKit-type infrastructure for the
site. Pages just generated an XML tree and apply 1 or more XSLT stylesheets.
There were more issues than I could posibly count (mostly my fault, I'm
sure, though my code was able to core dump mod_perl2!) with how I was
manipulating mod_perl and Apache which arose on the transition.

Anyhow, unfortunately for me, I'm using Error.pm exceptions all over the
place. One way I use it is for redirection: throw E:Redirect url =>
http://foo. And I'm wrapping the RegistryCooker handler (Registry handler in
mod_perl 1). I have a catch statement in my handler, though I guess I never
realized that my redirect trick was working by accident in mod_perl 1, and
now it doesn't work at all in mod_perl 2. (By accident because the
default_handler executes the page in an eval {})

The redirect exception object construction sets the Location header and
status code. With mod_perl 1 I guess this was enough to get the job done,
but with mod_perl 2 this just doesn't fly. (I Suppose now mod_perl 2 munges
the status code).

I guess what I'm asking is what's the quickest way to get the actual
behavior that I want; specifically, being able to throw exceptions into my
andler. Re-writing the default handler (which loads and caches the pages)
seems like the most work, so I'm looking for an easier answer, if any ;) For
that effort it seems I might was well grab Cocoon 3 and switch to Java.

- Bill

Apache2 / FilterRequestHandler oddity

Hi everyone,

I'm having a rather odd problem that I cannot figure out how to solve:
I've created a mod_perl2 output filter, but my mod_perl2 installation
won't load it - complaining something like

Can't add request filter handler 'Eremita::Test::handler' since it
doesn't have the FilterRequestHandler attribute set

The same code runs fine at other machines.

The machine in question is running openSUSE 11.0 / Apache 2.2.8 /
mod_perl2 2.0.4-dev.

My current test code looks like this:

package Eremita::Test;

use strict;
use warnings FATAL => 'all';

our $VERSION = 0.01;

use base qw(Apache2::Filter);
use Apache2::RequestRec ();
use APR::Table ();

use Apache2::Const -compile => qw(DECLINED HTTP_INTERNAL_SERVER_ERROR OK);
use APR::Const -compile => ':common';

use constant BUFF_LEN => 1024;

sub handler : FilterRequestHandler {
my $f = shift;

unless ($f->ctx) {
$f->r->headers_out->unset('Content-Length');
$f->ctx(1);
}

while ($f->read(my $buffer, BUFF_LEN)) {
$buffer =~ s/[\r\n]//g;
$f->print($buffer);
}

return Apache2::Const::OK;
}

1;

Googling doesn't reveal much - any hints?

Regards,
Lars

--
Lars Skjærlund
Skovengen 111
2980 Kokkedal
Denmark

Tlf.: +45 70258810

http://www.skjaerlund.dk/lars

Re: Apache2 / FilterRequestHandler oddity

On Sun, Dec 7, 2008 at 1:44 AM, Lars Skj=E6rlund wrote=
:
> The same code runs fine at other machines.
>
> The machine in question is running openSUSE 11.0 / Apache 2.2.8 / mod_per=
l2
> 2.0.4-dev.

Are the machines where it runs fine on the exact same versions of
apache and mod_perl? I suspect a different apache.

- Perrin

Re: Error.pm and RegistryCooker

On Sat, Dec 6, 2008 at 2:48 PM, William Ahern
wrote:
> I was forced to move from mod_perl to mod_perl2 because of Ubuntu.

Don't let Ubuntu push you around. If you want to run mod_perl 1, go
ahead. You don't need the Ubuntu packages.

> Anyhow, unfortunately for me, I'm using Error.pm exceptions all over the
> place. One way I use it is for redirection: throw E:Redirect url =>
> http://foo. And I'm wrapping the RegistryCooker handler (Registry handler in
> mod_perl 1). I have a catch statement in my handler, though I guess I never
> realized that my redirect trick was working by accident in mod_perl 1, and
> now it doesn't work at all in mod_perl 2. (By accident because the
> default_handler executes the page in an eval {})

Nested evals should work. However, I'd suggest you avoid the
try/catch syntax of Error.pm because it can lead to other problems.

> The redirect exception object construction sets the Location header and
> status code. With mod_perl 1 I guess this was enough to get the job done,
> but with mod_perl 2 this just doesn't fly. (I Suppose now mod_perl 2 munges
> the status code).

You're probably just not setting the headers correctly. Look at some
examples like these:
http://perl.apache.org/docs/2.0/user/coding/cooking.html

> Re-writing the default handler (which loads and caches the pages)
> seems like the most work, so I'm looking for an easier answer, if any ;) For
> that effort it seems I might was well grab Cocoon 3 and switch to Java.

It's actually intended to be easy to inherit from the base Registry
handler and change behavior. Check out ModPerl::RegistryCooker if you
ever need to do this.

- Perrin