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

I now need to stop using mod_perl 1 and I don't want to learn converting to mod_perl 2.
I have many large modules that use:

$r->print(qq{blah blah}); $r->print($bad_info);

I really don't want to go through all the code and ditch the $r->prints since I need to get this done sooner rather than later. I'm no OO code writer, so I could really use some suggestions about how to sneak in a quick and dirty fix for right now.
Any suggestions?

Replies are listed 'Best First'.
Re: quick fix for mod_perl $r->print when moving to FCGI
by afoken (Chancellor) on Mar 11, 2017 at 18:43 UTC
    I don't want to learn converting to mod_perl 2.

    That's quite sad. If you refuse to learn, you are at the wrong place.

    It took me about 60 seconds to find https://perl.apache.org/docs/2.0/user/porting/compat.html and https://perl.apache.org/docs/2.0/user/porting/porting.html. Quoting the latter:

    Using the CENSORED Layer

    The CENSORED module tries to hide the changes in API prototypes between version 1.0 and 2.0 of mod_perl, and implements "virtual methods" for the methods and functions that actually no longer exist.

    CENSORED is extremely easy to use. Either add at the very beginning of CENSORED:

    use CENSORED;

    or add to CENSORED:

    PerlModule CENSORED

    That's all there is to it. Now you can run your 1.0 module unchanged.

    Emphasis mine. And yes, I intentionally removed a key part of the information you need. This is to help you learn to RTFM.


    If you want to port mod_perl 1 code to FCGI, be prepared that not all functionality of mod_perl is available via the FastCGI interface. Nevertheless, you could replace the Apache modules by a class that has a similar interface, but instead calls FCGI methods or functions.

    For starters, try something like this:

    package NotQuiteApache; use v5.12; use warnings; sub new { my $class=shift; my $self=bless {},$class; # you may need to add some FCGI init here # you may need to add some data to %$self. return $self; } sub print { my $self=shift; return CORE::print @_; } # you may need to add more wrapper methods here 1;

    And in your code:

    # ... use NotQuiteApache; # ... my $r=NotQuiteApache->new(); # ... $r->print("Hello World!"); # ...

    (Both completely untested.)

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      I am certainly willing to learn and RTFM, yet I will point out that changing from Apache 1.39 with mod_perl 1 in a chroot to Apache 2.4 and mod_perl 2 in a chroot is a rather challenging task! Using OpenBSD, all web servers are run within a chroot, which also adds to the burden in a significant way! I have information that needs to remain private for my customers.

      The Apache2::compat module tries to hide the changes in API prototypes between version 1.0 and 2.0 of mod_perl, and implements "virtual methods" for the methods and functions that actually no longer exist.

      Unfortunately, perhaps because of my programming methods or not setting something correctly in all of Apache 2.4 many confs, it did not work.

      I tried very hard over several hours a day for about two weeks to find any information to help me progress past my difficulties. Oddly (Why?), I couldn't find anything at all to fill in my blanks.

      I am also writing new modules to fill in some missing functionality, but I stopped work on that due to the need to transition away from Apache and mod_perl 1.
      I would like to point out that within those two pages, there are several sections that point out to the authors that some sections are unfinished.

      I have been subscribed to the mailing list for several years now, but I have yet to receive any answers to my questions. As in no response at all. Why??

      RTFM is a standard and usually correct answer, yet between Apache 2 and mod_perl 2, there really are a lot of manual pages to read! Plus the added work of digging out all of the modules which have to be imported into the chroot.

      I don't have anything against mod_perl 2, per se, but if anyone can point me to any information that thoroughly speaks of concepts such as "this is how we do this in mod_perl 1 and this is a detailed explanation of how to accomplish this in mod_perl 2 and why this was changed".
      I'm puzzled why such a straightforward and important topic, at least as my searches failed to produce, is not out there.

      Are there any up to date books that fill this need? I don't object to buying one or two books, but computer books are not cheap.

      I enjoy mod_perl and its capabilities. If I could run a desktop/laptop without an internet connection, I would just stick to mod_perl 1 and an older version of OpenBSD, but I must have an internet connection to the server.

      Learning Apache 2.4, mod_perl 2 and working all that into a chroot really is a daunting task. Google does tailor its responses based on previous searches and search selections and IP address, Perhaps someone else might get search results more useful than I have?

        ++. This is a very good update on the Original Post that was most definitely lacking in quantity of information. It is clear you're willing to do anything to learn (including purchasing materials), and when we are aware, we do recommend literature or other materials as we see fit.

        Although I haven't been in the Apache/mod_perl game for many years, I'm hoping someone here can set you in the right direction.

        Failing that, you may have to provide a complete, minimized scenario, including code, that can reproduce the issue.