(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 - randolf@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 - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/
