(This reply to Dr. James Smith's message is also intended for Ashish Mukherjee...)
You're hooking in to more handlers than I typically do -- I hook into PerlAuthenHandler and PerlAuthzHandler (to implement a custom login system I created that uses one cookie, so it's been great that cookies are accessible at these stages), so that's two places (I found that I have to set up handlers for both or else neither works, which is fine because simply returning Apache2::Const::OK for authz is trivially easy). In my test environments, I use PerlInitHandler with Apache2::Reload, which I find does come with a slight performance hit, but that's okay because they're not as busy as the production environments. So, aside from that I use PerlRequire to load my main module (which includes the "authen" and "authz" handlers), and then I use the following stanza in a VirtualHost container in httpd.conf to handle all .pl files with mod_perl: <FilesMatch "(\.p[lm]|^[^\.]+)$"> SetHandler modperl PerlOptions +SetupEnv PerlResponseHandler ModPerl::Registry AddOutputFilter INCLUDES .pl Options +Includes +ExecCGI </FilesMatch> My main Perl module, at the authen() stage, connects to PostgreSQL with DBI using connect_cached, and then stores a referenced to itself with $r->pnotes, which is later used by all the .pl files in my web sites to use the same database connection (why waste CPU resources by reconnecting and re-processing the cookie twice when we can just re-use what's already been established in the authen() stage?). One of the nice things about using the pnotes mechanism is that it also means that I can write my .pl files in a generic manner so that they can easily be copied to other web sites that use different main modules (as long as I support the same functions for generating headers and footers, and other web site styling, which I do). For me, mod_perl has been an amazing productivity tool, and I've been building nearly all my web sites with it (where I don't use mod_perl is when all I need is plain HTML without any server-side functionality). One of the greatest things about using mod_perl is the consistently high performance it provides, even when enduring heavy traffic loads (there are limits, of course, but comparatively I find that mod_perl handles a lot more traffic than many other systems like PHP, and so hardware infrastructure costs are less overall too). > I agree with Randolf, > > I have watched a number of projects move away from mod_perl - often to > Dancer/ > Catalyst etc and then they ask can I do X, Y or Z... > > I say "if you were using mod_perl you could do that easily" but usually > find the tool chain for > doing something similar in Dancer or Catalyst is infinitely more > complex, because you can't > simply add a handler here or an output filter there. You can do this > with chained middleware > in Dancer but it is not that easy to implement... > > The main thing with mod_perl is - as long as Apache doesn't mess around > with the core HTTPD > interface (like they did with 2.4) then there isn't anything much that > needs changing - because > it is good solid and just works... If it ain't broke then it doesn't > need changing. > > I probably use more "pure" mod_perl - no registry scripts here thank > you! - and hook into the > apache process at about 7- 8 places to handle users, templating, > diagnostics, optimisation etc > > On 14/08/2015 18:51, Randolf Richardson wrote: > >> Hello, > >> > >> I wanted to enquire about the status of mod_perl, since there is largely an > >> impression it is end of life. The project site also does not say much. I > >> see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc. > >> or going the Java way. > > I'm still using mod_perl to develop new web sites. The most recent > > one I've published is called the "atheist Blog Roll" and it uses a > > PostgreSQL database in the back-end: > > > > http://www.atheistblogroll.com/ > > > > There are other projects on my horizon that continue to be developed > > in mod_perl, and they range from simple web sites to fully > > interactive projects. > > > > When there is a need for a client-side application, I use Java > > because I only have to write the code once to gain support on > > multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if > > it needs to interact with a web site, then I typically use mod_perl > > for that end of things. > > > > For one of the projects I'm working on (which is not ready for > > public consumption quite yet), I've also written a WHOIS server using > > mod_perl (which listens on TCP port 43, and responds to queries based > > on its findings in PostgreSQL) to facilitate public membership record > > lookups (only for the portions that will be publicly accessible). > > > >> What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade > >> path recommended by the mod_perl veterans? > > When I upgrade, I'm normally installing new server hardware and so I > > migrate sites over one at a time, and resolve any API change > > requirements before promoting the new server to production (followed > > by log file merges after switching servers and traffic to the old > > servers cease). > > > >> Regards, > >> Ashish > > Randolf Richardson - rand...@inter-corporate.com > > Inter-Corporate Computer & Network Services, Inc. > > Beautiful British Columbia, Canada > > http://www.inter-corporate.com/ > > > > > > > > -- > The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a > company registered in England with number 2742969, whose registered > office is 215 Euston Road, London, NW1 2BE. Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Beautiful British Columbia, Canada http://www.inter-corporate.com/