cLive ;-) has asked for the wisdom of the Perl Monks concerning the following question:

This is more of a "rubber duck" debug than anything, but I've reached a point where I think I need an external set of eyes.

I'm tasked with migrating a mod_perl app to mod_perl 2. For the last couple of weeks, it's been reasonable (run code, get error, convert code call, check it works, move on...). But now I've hit a wall and I'm not sure how to proceed.

The app uses chained PerlResponseHandlers (was PerlHander in mp1) to process plain CGI scripts and thern to wrap them in a presentation layer (this is a really old school framework, and I'm not meant to be improving it, just get it to work).

The apache config for the section I'm on is like this:

<Directory /path/to/mp> SetHandler perl-script PerlAccessHandler APP::Phase::Authen PerlResponseHandler APP::Page ModPerl::Registry Options ExecCGI </Directory>

The APP::Page module inherits from Apache::Forward, a local module based on code "Taken from Stein & MacEachern's book" (which I don't have a copy of with me, alas :) Here's the handler code from the module:

sub handler ($$) { my ($class, $r) = @_; my $next = tied *STDOUT || return SERVER_ERROR; tie *STDOUT, $class, $r, $next or return SERVER_ERROR; $r->register_cleanup( sub { no warnings 'untie'; untie *STDOUT; }); OK; }

There's also TIEHANDLE, PRINT and forward methods in the class. Two things I notice when running this under mod_perl2:

I'm not 100% sure how the chained handlers work. I assume from right to left in the Apache config. But what about the tied STDOUT? Is that meant to be being defined explicitly somewhere initially? I grepped the code base for other ties to STDOUT, and I can't see any outside of this module.

I tried just dropping in use Apache2::compat into, but that doesn't appear to have any affect on this.

I also notice in 15.4 of the ModPerl Cookbook a section on Filtered content where PerlSetVar Filter On is added to the config. Now I'm wondering why this code doesn't use that and whether I should be migrating the code to use it? Hmmm.

The mod_perl migration guide doesn't have any info on this. I'm assuming I should be reading up on details of stacked handlers or something similar. What should I be reading to get up to speed on how this worked under mod_perl 1, and how to get it working under mod_perl 2? (and any other insights welcomed).

Update: Found this presentation, which pretty much covers what I need to know. Long story short I need to look at Apache2::Filter

Replies are listed 'Best First'.
Re: Migrating mod_perl app to mod_perl 2
by McA (Priest) on Oct 31, 2014 at 20:25 UTC

    Hi cLive,

    I can't help you directly. But on the mod_perl mailing list are some very knowing people which may have a solution for you.

    Probably you can adress Torsten Förtsch (mod_perl specialist) on that list directly.


      Thanks for the suggestion. I'm going to go through all the mod_perl and mod_perl 2 docs first though so I'm sure I know what it is I don't know before bothering them. The stacked handlers info here is pretty good at giving me background on mod_perl's initial implementation of this, so I'm hoping I can soak up enough info to resolve this myself. Such a steep learning curve though - I haven't touched mod_perl in almost a decade :D
Re: Migrating mod_perl app to mod_perl 2
by grantm (Parson) on Nov 03, 2014 at 20:49 UTC

    Quick suggestion (haven't got time to fully research - sorry). If your handler is not being called as a class method, maybe you should change the declaration to look like this:

    sub handler : method { my($class, $req) = @_; ... }

    I vaguely recall that the method vs function distinction changed from being declared by a prototype to an attribute some time in the mod_perl 1 days.

      Thanks - that does indeed bring the class back into @_

      Now i just need to work out what's up with the tied *STDOUT (and I've been making progress - I'll update this when I get to the solution so that there's a public reference for others later).