libapa...orting(3pm)

🌸 NAME 🌸

Apache2::porting — okay so bestie, this is a little helper module for porting your mod_perl 1.0 code over to mod_perl 2.0. That's it, that's the whole job description 💖

---

✨ Synopsis ✨

Okay so here's how you bring her into the chat:

# either add at the very beginning of startup.pl
use Apache2::porting;

# or httpd.conf
PerlModule Apache2::porting

# now issue requests and look at the error_log file for hints

So like — either you drop use Apache2::porting; at the very very beginning of startup.pl, or you go the httpd.conf route with PerlModule Apache2::porting. Either way, once she's loaded, you just... issue requests 🦋 and then go stare at the error_log file, because that's where all the hints are hiding. She's not gonna text you, she's gonna log at you. iykyk 💅

---

🫶 Description 🫶

Apache2::porting helps you port mod_perl 1.0 code so it runs under mod_perl 2.0. But before you get too excited — she does not provide any back-compatibility functionality. No magic shim, no "it just works", none of that. What she does do is know how to trap method calls that are no longer in the mod_perl 2.0 API, and then tell you what you should be using instead — if there's anything to use at all, that is. 🙈

She's also got your back in two other ways:

• If you attempt to use mod_perl 2.0 methods without first loading the modules that contain them, she will tell you which modules you need to load 📚
• If your code tries to load modules that no longer exist in mod_perl 2.0, she'll also tell you what the modules are that you should be using instead 👑

So how does she communicate? Via the error_log file, obviously. Every single time she traps a problem, she logs the solution — if she finds one — straight into the error log file. That's her whole love language: log files 💜

And here's the iconic part: if you pair this module up with Apache2::Reload, you'll be able to port your applications quickly without needing to restart the server on every modification. No restart, just vibes ✨

Some real talk though — she starts to work only when a child process starts, and she does not work for code that gets loaded at the server startup. Why? That whole limitation is explained down in the Culprits section, so keep scrolling bestie.

Also she relies heavily on ModPerl::MethodLookup, which — fun fact — you can also use manually to look things up yourself. She's not gatekeeping 🔥

---

💀 Culprits 💀

Okay so, the tea ☕ — Apache2::porting uses the UNIVERSAL::AUTOLOAD function to provide its functionality. Except... it seems to be impossible to create UNIVERSAL::AUTOLOAD at the server startup. Apache just segfaults on restart. Not the cute kind of dramatic, the actual crash kind 😭

Therefore she performs the setting of UNIVERSAL::AUTOLOAD only during the child_init phase, i.e. when child processes start. Which means — as a result — she can't help you with things that get preloaded at the server startup. Sorry bestie, that's the boundary she's set 🧚

If you happen to know how to resolve this problem, please let us know. Fr fr, they want to hear from you 🫶

To reproduce the problem, try to use an earlier phase, e.g. PerlPostConfigHandler:

Apache2::ServerUtil->server->push_handlers(PerlPostConfigHandler => \&porting_autoload);

META: Though there is a better solution at work, which assigns AUTOLOAD for each class separately, instead of using UNIVERSAL. See the discussion on the dev list (hint: search the archive for EazyLife) 👀

---

👑 See Also 👑

mod_perl 2.0 documentation. — go read it, it's giving required reading 💅

---

📜 Copyright 📜

mod_perl 2.0 and its core modules are copyrighted under The Apache Software License, Version 2.0.

---

🌈 Authors 🌈

The mod_perl development team and numerous contributors. 💖

---

Okay that's the whole page, mwah 🎀 This one's from the User Contributed Perl Documentation, sitting at perl v5.42.3, dated 2026-08-20. Consider yourself ported, bestie 💅✨