Wrapping mod_perl in Plack

Plack is one of these wonderful adventures in the modern Perl world that makes it fun to write Web applications in Perl again. But I have a few applications written with Apache/mod_perl and they are not fun to work with. So what would you do?

One option would be to take the long road and port these apps to use Plack instead of messing around with Apache2::RequestRec. For this to work you might need to review the full code base before seeing any signs of progress.

Another option is to mock your Apache2::RequestRec object using Plack. This is the road explored by Plack::App::WrapApacheReq. With very little work this enables you to run your mod_perl application with any Plack handler you want. You can run your application as a stand alone server or serve it with nginx trough FastCGI.

But the fun doesn’t stop here. Debugging and profiling mod_perl have always been a PITA, but with Plack::App::WrapApacheReq it is easy. Just take the generic.psgi example and it enables you to run the Perl debugger easy or just to use NYTProf on your request handling code.

The initial ideas for writing Plack::App::WrapApacheRec came from my mocking code to test a legacy mod_perl application. Even this gets more fun by using Plack. I havn’t tested it yet, but with Plack::Test and Plack::Test::ExternalServer it should be trivial to run the same set of tests directly in a single process test suite or against your deployed server.

Plack::App::WrapApacheRec is still in it’s infancy. It only mocks as much of Apache2::RequestRec as I need to run a single legacy application and to run Plack::Handler::Apache2 (as an absurd example, but yes we are self hosting). But I think that with very little work we should be able to run most mod_perl applications. Take it out for a ride, if it complains about a missing method please report it with CPAN’s RequestTracker. Patches would be appreciated (or pull requests on github), but just a list of unimplemented method you need would be excellent.

Plack is fun, now working with mod_perl applications might become fun too.

5 Comments »

  1. Adam said,

    November 30, 2010 @ 9:04 pm

    Probably a very stupid question, but since you mention how fun it is quite a number of times, I am getting curious: What does Plack exactly do and what makes it fun?

    (For context: I don’t know what Ruby’s Rack nor Python’s Paste do, and PSGI is a four-letter acronym to me; FastCGI I have some limited experience with.)

  2. hdp said,

    December 1, 2010 @ 2:53 am

    http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI/FAQ.pod#I'm_writing_a_web_application._What's_the_benefit_of_PSGI_for_me?

    Being able to run the same request handling code in a test, over FastCGI, as HTTP behind a reverse proxy, as a standalone server for development, etc. is really, really convenient.

  3. Peter Makholm said,

    December 1, 2010 @ 6:28 am

    Fun may be a bit of an exaggeration.

    It is very convenient to be able to run the same request handling code directly by you test suite, as a standalone server, and deployed in multiple ways.

    The fun part is that it removes some of the bothersome tasks of developing with mod_perl. Running as a standalone server everything is Perl (and Perl is fun, remember?). No need to magically understand the Apache request cycle or the request object, everything is introspectable as other Perl structures.

  4. Schwern said,

    January 22, 2011 @ 2:38 am

    I’m wondering if you think the technique would work as well for Apache v1?

    I’m faced with a rather old, hairy business web app that’s deeply in bed with Apache 1 even going as far as to write its own config files. I’ve been tasked with doing the minimum so it can be tested and deployed on a modern Debian machine, then we’ll have breathing room for a full rewrite. Converting it to Plack is proving a lot of work. It might be easier to just emulate the bits of the Apache API that it uses. The config files will be more work.

  5. Peter Makholm said,

    January 27, 2011 @ 10:27 am

    I don’t really remember anything about the difference between Apache1 and Apache2. But I don’t see any reason it should be harder to do the same for Apache1.

    One option that could ease the task would be to look at Apache::Fake, which just seem to have gotten a new maintainer.

RSS feed for comments on this post · TrackBack URI

Leave a Comment