Help Test mod_perl 2 Release Candidates

← Back to Stories (view on slashdot.org)

Help Test mod_perl 2 Release Candidates

Posted by timothy on Sunday December 26, 2004 @02:53AM from the yes-master dept.

stas writes "After almost 3 years of work mod_perl 2 is almost ready for its 2.0.0 release. We plan to make the gold release in a few weeks. Please help to test the release candidates by starting to port your mod_perl 1 applications to mod_perl 2. Make sure to read the documentation and report any problems that you may have discovered. Thanks."

54 comments

Min score:

Reason:

Sort:

Is mod_perl a legacy technology? by LizardKing · 2004-12-26 04:07 · Score: 2, Interesting

Not a troll, but something I'm genuinely wondering about - haven't things like J2EE, .Net and PHP made mod_perl obsolete? Back in the bad days of the web, the choice was C or Perl hooking directly into the Apache API to avoid spawning too many processes. Then along came Java servlets or ASP for those drawn to the dark side. Would anyone really consider mod_perl for a serious sized web application any more?
1. Re:Is mod_perl a legacy technology? by sporty · 2004-12-26 04:21 · Score: 3, Insightful
  
  Uh. noo... mod_perl is old as an idea, but it's certainly not legacy in the same way that dbase is legacy. Only thing bad about mod_perl is trying to use it with apache2 in its threaded mode.
  
  Btw, php does not make mod_perl obsolete. Yes, php can be hosted in a lesser secure area, as php scripts assume the user its running as, but that's about it. It's an ugly language full of redundancy, bugs and inconsistent style. j2ee and .net, not so much.
  
  Biggest problem with php, is their "modules" are c-compiled. There is the least portability with it. With perl, perl written modules, not the XS modules, can be easily copied anywhere. j2ee not so much, as the configuration files change format from server to server. But from os to os, they are the same.
  
  --
  -
  ping -f 255.255.255.255 # if only
2. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-26 04:22 · Score: 4, Informative
  
  Well, there is of course slashcode, and Amazon.com also uses mod_perl and HTML::Mason (see http://www.masonhq.com/?AmazonDotCom/). I'm sure there are many others as well.
3. Re:Is mod_perl a legacy technology? by Airwall · 2004-12-26 04:33 · Score: 4, Informative
  
  It's not really fair to equate mod_perl to per-page interpreted languages.
  mod_perl, and to a certain extent Java servlets, gives you a huge amount of power over the web serving process, and are suitable for developing web applications that can do almost anything with HTTP.
  PHP, ASP and the like give you a per-page interpreted language, oriented to producing one page of HTML at a time. They are much easier to get started with, and they're the "right" choice for most websites.
  Of course middle-men between the two camps exist: Servlets have JSPs, for example, which obey a per-page paradigm but are run by servlets. There are also third-party templating system with greater or lesser degrees of flexibility/depth/power (Tapestry is a particularly impressive one.) My own website (http://n3dst4.com , rather than the one in my profile) is written in Mason, which is an interpreted component and template layer on top of mod_perl. Because of the depth of control that mod_perl has, Mason can do some things that PHP can't, like having a completely programmable request handler, global or per-directory pre-handlers, a seamless component model).
  I'm not dissing PHP, though. The site in my profile (Sacred Steel) is written in PHP, because it was the right tool for that job.
  Oh, and remember that .net and J2EE are allegedly complete enterprise programming platforms, while mod_perl is just one specific technology for web application programming.
4. Re:Is mod_perl a legacy technology? by Airwall · 2004-12-26 04:37 · Score: 2, Insightful
  
  The Register uses Bricolage, a content management system written with Mason, a mod_perl application. It's a bit of a stack, but it works good.
5. Re:Is mod_perl a legacy technology? by Airwall · 2004-12-26 04:45 · Score: 1
  
  Oops. In true Slashdot style I fired my mouh off and then went to check the facts. At this page they describe their system as "a custom content management system which is written in Perl" and don't mention Bricolage or Mason anywhere.
6. Re:Is mod_perl a legacy technology? by plcurechax · 2004-12-26 06:51 · Score: 1
  
  haven't things like J2EE, .Net and PHP made mod_perl obsolete?
  
  No, just because there is something newer and flashier I am not going to rewrite a C/Perl system to J2EE or .Net for no substancial gain in the end product.
7. Re:Is mod_perl a legacy technology? by KeyserDK · 2004-12-26 07:29 · Score: 2, Interesting
  
  I'm actually developing new sites with AxKit.
  
  --
  still reading?
8. Re:Is mod_perl a legacy technology? by sporty · 2004-12-26 07:54 · Score: 1
  
  A minor quib. JSPs get compiled into servlets, usually. At least tomcat does. It turns the jsp into java source extending servlet or something like.
  
  --
  -
  ping -f 255.255.255.255 # if only
9. Re:Is mod_perl a legacy technology? by Airwall · 2004-12-26 09:25 · Score: 1
  
  How's it going? AxKit simultaneously fascinates me and frightens me.
10. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-26 09:54 · Score: 0
  
  Btw, php does not make mod_perl obsolete. . . . It's an ugly language full of redundancy, bugs and inconsistent style.
  
  Funnily enough, that's roughly what most Perl-haters say about Perl.
  
  Come to that, I thought "redundancy" and "inconsistent style" were among the things that its advocates claim as Perl's greatest strengths - you know, all that TMTOWTDI stuff?
11. Re:Is mod_perl a legacy technology? by consumer · 2004-12-26 14:32 · Score: 1
  
  Actually, mod_perl is running larger sites than Java or PHP right now. ticketmaster.com, citysearch.com, imdb.com, and of course slashdot itself. Although they don't use mod_perl, Yahoo and Amazon use Perl for major parts of their sites. So, it is a popular choice for building very large sites.
  Coding with mod_perl is nearly identical to using Java servlets or ASP in terms of the processing model.
12. Re:Is mod_perl a legacy technology? by consumer · 2004-12-26 14:35 · Score: 1
  
  FYI, if you run PHP as an apache module, it does not run with the privileges of the user. That only happens if you run it through CGI, and of course the same is true of Perl when run through CGI.
13. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-26 18:14 · Score: 0
  
  slashdot is down frequently (500 server error type stuff). bad example. :)
14. Re:Is mod_perl a legacy technology? by ahdeoz · 2004-12-26 22:11 · Score: 1, Interesting
  
  I'm thinking of switching to mod_perl, and I don't even like perl. I have alot of PHP pages that load just way too much on every request, and a lot of custom built servlet-frameworks because I don't like any of the existing java frameworks. Lately I've come to the conclusion (and reaffirmed by Rod Johnson's J2EE books) that it's really okay to put your application stack all together as long as it's logically separated. My only complaint is that it seems most of the perl knowledge is locked up in the minds of perl gurus, though I'm always amazed at what I find on CPAN when I go looking for something (recently, a EAN to ISBN converter written by a librarian in Tampa, thanks; although it took longer to install all the modules than it would have to learn how to calculate the checksum myself -- and of course CPAN broke after a few and I ended up copying several manually after their Makefile.PL choked and then I had to create a no-op module to get it to run.
15. Re:Is mod_perl a legacy technology? by ahdeoz · 2004-12-26 22:13 · Score: 0, Flamebait
  
  BTW, is there such a thing as a perl framework? No, not mason or something like that. That's like using smarty. I'll just include my PHP pages thanks, or embperl, but I'm not liking the idea of just having environment variables with global scope where my pages slurp up all the info done in the mod_perl pre-processing.
16. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-26 22:38 · Score: 0
  
  Hate to burst your bubble, but: The largest web site -- Yahoo! -- runs on PHP. Yahoo! is migrating all properties as they call their various services to PHP as templating engine. The business logic remains primarily in C++.
  
  Story here:
  
  http://news.com.com/2100-1023-963937.html?tag=lh
17. Re:Is mod_perl a legacy technology? by sporty · 2004-12-27 01:13 · Score: 1
  
  You are right. But it mimics the uid of the user set for the file in question as if it were that uid.
  An error in my phrasing of that.
  
  --
  -
  ping -f 255.255.255.255 # if only
18. Re:Is mod_perl a legacy technology? by kwoff · 2004-12-27 01:36 · Score: 1
  
  I happen to know that they do use Bricolage. See also http://www.theregister.co.uk/2003/05/30/the_regist er_signs_up/
19. Re:Is mod_perl a legacy technology? by Airwall · 2004-12-27 03:25 · Score: 1
  
  That's what I was remembering, but I couldn't find any stories to say they'd actually gone live with it. You got any more info?
20. Re:Is mod_perl a legacy technology? by consumer · 2004-12-27 05:17 · Score: 1
  
  Not true, and I have it directly from several Yahoo employees. They uses PHP for a bunch of server-side include type of stuff, but a huge amount of their business logic is in perl. Nearly every property in Yahoo uses Perl, especially My Yahoo. They do lots of pre-generation of pages with Perl and then stitch things together with PHP when serving requests.
21. Re:Is mod_perl a legacy technology? by consumer · 2004-12-27 05:19 · Score: 2, Informative
  
  There are several frameworks for Perl.
22. Re:Is mod_perl a legacy technology? by ahdeoz · 2004-12-27 16:08 · Score: 0, Flamebait
  
  I meant more than a simple include or template. Perl can already read files and do regex search and replace. Something to handle security, sessions, action-chaining, application state, data validation, resource pooling, etc., beyond what is provided by the Apache API and miscellaneous packages like DBI that I handle manually. So either your answer is "no" or "I don't know" -- which is it?
23. Re:Is mod_perl a legacy technology? by consumer · 2004-12-27 17:23 · Score: 1
  
  You clearly didn't actually read about the frameworks I pointed you to if you think they are just templating tools. Start with OpenInteract.
24. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-27 22:25 · Score: 0
  
  Absolutely! I myself am using it for an Intranet solution for a small to medium sized company. For my purposes, Perl is so much nicer to work with than JSP or Java Servlets. As alwyas, your milage may vary.
25. Re:Is mod_perl a legacy technology? by duncangough · 2004-12-28 01:18 · Score: 1
  
  Ahahha - good luck!
  
  Playaholics: Free online games: Lightning Pool
  
  --
  Suttree, a weblog about casual games development
26. Re:Is mod_perl a legacy technology? by cwinters · 2004-12-28 03:45 · Score: 1
  
  And if you do start with OpenInteract, I strongly recommend using the recent beta of OpenInteract 2, which has a much better design and documentation than the first version.
  
  --
  Chris
  M-x auto-bs-mode
27. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-28 05:56 · Score: 0
  
  php is "an ugly language full of redundancy, bugs and inconsistent style", in context of Perl discussion?
  
  Mod the parent "Funny", please!
28. Re:Is mod_perl a legacy technology? by ahdeoz · 2004-12-28 10:38 · Score: 0, Flamebait
  
  I did read every one of them. OpenInteract looks like a good starting point, but it doesn't look like it has much of a user base, and probably won't fit my usage. I was expressing my contempt earlier for people who suggest something like Mason as a framework when I complain about PHP.
29. Re:Is mod_perl a legacy technology? by LordMyren · 2004-12-28 11:58 · Score: 2, Insightful
  
  mod_perl, and to a certain extent Java servlets, gives you a huge amount of power over the web serving process, and are suitable for developing web applications that can do almost anything with HTTP. (emph. mine)
  
  even as you attempt to broaden the sense that mod_perl is more than just some content generating script, you undermind the essence of what you talk about.
  
  mod_perl is capable of being used to write entirely different protocol handlers: you can make apache serve FTP or ssh with mod_perl, if you're insane enough to do so. it can completely alter the flow of information at any step in the proces, thanks to apache's beautiful filtering & module structuing.
  
  as you state, mod_perl uses the apachi api to tie itself deeply into the apache server engine itself, performing all sorts of reconfiguration of apache. `tis truly divine.
30. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2004-12-29 12:39 · Score: 0
  
  Let's see... It's faster, cleaner programming with libraries such as Mason and Maypole, and not a big gaping security hole waiting to happend, such as PHP is?
31. Re:Is mod_perl a legacy technology? by wwahammy · 2004-12-29 19:17 · Score: 2, Insightful
  
  I don't see why they wouldn't. I really think it comes down to what best fits your situation and what skills you have. I think PHP is great and I'm a casual programmer but I think the lack of namespaces can be super confusing in large projects. I've used Perl and its got tons of features and mod_perl is incredibly fast but its to say the least confusing. .NET is stuck to MS servers to the most part. Its just using what works best for you.
32. Re:Is mod_perl a legacy technology? by draven · 2004-12-30 00:02 · Score: 1
  
  You might want to take a look at Maypole (http://maypole.perl.org/).
  
  From the blurb:
  Maypole is a Perl framework for MVC-oriented web applications, similar to Jakarta's Struts. Maypole is designed to minimize coding requirements for creating simple web interfaces to databases, while remaining flexible enough to support enterprise web applications.
  
  (Note that I'm not fully objective as I'm one of the developers working on Maypole ;-)
  
  --
  -- Marcus Ramberg
33. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2005-01-03 23:52 · Score: 0
  
  http://maypole.perl.org/
  
  FYI: to create a link you need to use an Anchor tag, the spec for the Anchor is here.
  
  But here is a brief example of a "link", "hyperlink"
  
  <a href="http://maypole.perl.org/">Maypole</a>
  
  I used your site in the example but you could replace http://maypole.perl.org/ with any URL from the internet, and Maypole could be any text
  I was suprised that you couldn't create a link seeing that your working on a project that generates web interfaces. Shocking.
34. Re:Is mod_perl a legacy technology? by Anonymous Coward · 2005-01-04 18:16 · Score: 0
  
  > JSPs get compiled into servlets, usually.
  
  s/usually/always/
  
  it's part of the JSP spec. You can even choose which servlet class to instantiate, which can give you some coarse control over its operation (not a lot, since the translation to java code is not highly specified, but it's always pretty rough)
35. Re:Is mod_perl a legacy technology? by nihilogos · 2005-01-04 18:46 · Score: 1
  
  It's an ugly language full of redundancy, bugs and inconsistent style
  
  You can't say it's uglier than Perl. Although at least Perl doesn't gives you error messages like "unexpected T_PAAMAYIM_NEKUDOTAYIM" which is only funny to anyone who speaks Hebrew.
  
  --
  :wq
36. Re:Is mod_perl a legacy technology? by Cap'n+Steve · 2005-01-05 19:13 · Score: 1
  
  I also seem to remember Wired mentioning that the Internet Movie Database uses perl.
porting okay except unfinished documentation by plcurechax · 2004-12-26 06:46 · Score: 1

Well I did a port from mod_perl 1 to mod_perl 2 many months ago, and it wasn't too bad except for the lack of completed version 2 documentation and I wished I had more examples available to me. Most of the docs then were about 50 to 80 percent completed.

The porting itself was painless when I wasn't trying to set up a build environment across multiple Apache and perl versions and using libapreq2 (lib ApacheRequest) and mod_perl2 (well 1.99).
1. Re:porting okay except unfinished documentation by LordMyren · 2004-12-28 12:00 · Score: 1
  
  whether i'm developping c++ or perl modules for apache, I use the mod_perl 2 docs. they are truly fantastic.
  
  a huge shout out to the mod_perl team for not only documenting their own efforts, but for finally making some sense of Apache's scattered api.
"use Apache2" considered harmful by merlyn · 2004-12-26 08:32 · Score: 3, Informative

Keep in mind that this release does not play well with others, especially prior mod_perl1 installations.
In order to have two different versions of things like Apache::Request (which have changed implementations without changing names), the modules get installed as $libdir/Apache2/Apache/Request.pm. Of course, you're then expected to "use Apache2" to add $libdir/Apache2 to your @INC path. Of course, this breaks every other element of the Perl toolchain that expects that @INC is not changed in such a radical fashion.
This release currently has problems with the PAUSE indexer, the CPAN installation tools, perldoc, and installation of manpages, because they all expect @INC to not be so badly hacked. Stas is trying to work out solutions with the community, but mostly in the form of "This is the way modperl2 works, please fix all your tools", and that's not flying well.
So, beware to those who install this release.
--
- Randal L. Schwartz, Just another Perl hacker for Stonehenge
1. Re:"use Apache2" considered harmful by Anonymous Coward · 2004-12-26 20:36 · Score: 2, Insightful
  
  Remember also that under Windows AP2/MP2 is the only stable option currently available.
  
  Personally I have been using MP2 in production on windows for well over a year - call me an early adopter :-)
  
  FYI the only problem the windows install has ATM is the a bug that took from perl5.8.3 to perl5.8.6 to fix.
  
  On the linux side the benefit of the reduced memory profile and increase in performance we have seen is enough to migrate new installations to AP2/MP2. We have yet to have a problem on the Linux side and no longer see swapping.
  
  Stas and the team overloaded the Apache:: namespace to make MP1 to MP2 migration easier.
  Why no one perlish (including myself or randall) complained at the time is inexcusable.
  I should have spotted this problem then and for that I apologise to Stas and the team.
  
  Regarding not using AP2/MP2 I think that this will (hopefully) have little effect.
  
  The windows folks use PPM's which do not rely on PAUSE/CPAN model.
  
  On the linux side AP2/MP2 tends to be the choice of commercial distributions.
  
  Getting people to step back down the ladder because even more stuff can no longer be found on CPAN will hopefully not happen.
  
  Personally rather than backbiting we should be trying to extend CPAN to cover the more generic problem of external dependencies, rather that trying to ignore it or assign blame.
  
  After all perl interfaces to a lot of systems and I do not want to see versioned namespaces such as ApacheN XML2 etc for even more external dependancies.
  
  Jacqui dot Caren
  at
  mymail.aixx.com
2. Re:"use Apache2" considered harmful by Anonymous Coward · 2004-12-29 22:35 · Score: 0
  
  Unfortunately, now that the general perl community has been made aware of this overloaded Apache:: problem, it is becoming apparant that it is going to be literally impossible to allow overloading of modules in the way that it has been done.
  
  It's looking like the release may have to be put on hold for now until it's moved to Apache2:: or something similar.
  
  Fortunately, since the API in general won't change much, those early adopters will just have to s/Apache::/Apache2::/ and everything will "just work".
  
  It would appear that after some examination the only way to make the overloaded modules idea fly results in a cascade of changes at the end of which we would have to fork perl itself, or something equally as drastic.
Thanks to the developers by Yo+Maing · 2004-12-26 17:03 · Score: 1

I've been using mod_perl2 over a year now, and it rocks hard. I've got my SMTP handling done through Apache::Qpsmtpd, and I'm currently created a DAV handler for mod_perl2.
1. Re:Thanks to the developers by kwerle · 2004-12-26 17:35 · Score: 1
  
  Out of curiosity - what on earth do you need Qpsmtpd attached to apache for?
2. Re:Thanks to the developers by consumer · 2004-12-27 05:25 · Score: 1
  
  It gets better performance that way.
3. Re:Thanks to the developers by Yo+Maing · 2004-12-27 06:27 · Score: 1
  
  It's also easier to manage and tune. Plus it's just damn cool.
To accelerate my cgi scripts by Anonymous Coward · 2004-12-26 19:53 · Score: 0

I looked at mod_perl but found it overkill for what I needed (it offers alot of powerful features that I may look into though). I've had alot of success with mod_fastcgi (and FastCGI.pm). mod_fastcgi also creates persistant processes which cuts down _dramatically_ on the time to execute (well, mostly load) your cgi scripts. Of course, at the expense of a bit of RAM.
mod_perl by sigma3dz · 2004-12-27 09:08 · Score: 1

Would anyone really consider mod_perl for a serious sized web application?
1. Re:mod_perl by consumer · 2004-12-27 17:27 · Score: 1
  
  If you read the rest of the comments you'll see that it is already being used for applications larger than most people every work on.
2. Re:mod_perl by Silent1 · 2004-12-27 18:46 · Score: 2, Informative
  
  slashdot big enough for ya?
3. Re:mod_perl by Anonymous Coward · 2004-12-28 02:39 · Score: 0
  
  What about E-Toys? Ticketmaster? I'd consider those "serious sized" ...
4. Re:mod_perl by innerweb · 2004-12-29 22:59 · Score: 3, Informative
  
  Are you kidding? PHP, Java and the rest do not have bigger applications than what are done in Perl using mod-perl!
  It has more of a learning curve than php at first, and probably is not appropriate for small static sites, but I have never seen PHP or Java rip out major stuff as fast as Perl, then migrate, modify or otherwise perform client expectations that require redesign. I have worked for two companies where we went to Java. At both companies, more than half the stuff that went to Java was sent back to perl to decrease response time for client needs. Another company I contract to went to PHP for their site when they started, but wound up re-writing the whole thing in Perl with mod_perl when they had a database change. It was faster, and the code came out more manageable, faster and more stable. We learned very quickly that a programmer who writes bad code does it in all languages, and all the good programmers wrote clean concise well documented code (most of the time). And when they wrote something sloppy, it was no more difficult to figure out what they had written than it was in the other languages (Java, php, C, C++, sql, ...)
  
  It is very simple. I am paid by my clients to provide, maintain and modify code. They expect that I will charge them less than others and provide strong solid support and service. Most of them expect one day to one week turn around for change requests. Since we manage the code ourselves, it is very important to us that the code be quick, clear and concise. It must be as reuseable as possible. It must be able to be picked up with and run by new people or contractors. The Java took too long to make the same things happen and PHP ran into dead ends (could not, or more often took too long) when upgrading sites, migrating to new client databases or other client changes. In short, Perl has allowed us to undercut almost all of our competitors in this area. The ones we have not undercut are, believe it or not, perl based shops as well. Java does beat perl for some things as does php for some things, but in so many cases, perl has beat them both.
  
  InnerWeb
  
  --
  Freud might say that Intelligent Design is religion's ID.
One complaint about mod_perl by davegaramond · 2005-01-03 13:32 · Score: 1

Is that there's currently no way to restrict Perl* directives from being specified in .htaccess files. This makes it insecure for hosting servers to use mod_perl. Server admin certainly doesn't want normal clients to access mod_perl. Otherwise, mod_perl could be useful for server admins to customize their webserver.

mod_ruby on the other hand now has RubyRestrictDirectives to do exactly that.