Recently I was trying to make some mod_perl 1.0 module compatible with mod_perl 2.0 (at the same time), and saw all the differences in the new mod_perl 2.0.

First off please remember that mod_perl 2.0 is not finished yet. As far as I am aware there isn't a date for a point release in sight. There are certainly many holes in the documentation and a few in the implementation. I'm sure the developers would welcome patches ;-)

If you just need to run some mod_perl 1.0 code under mod_perl 2.0 take a look at Apache::compat. If this isn't working for you please submit a bug report to the development team.

First, I didn't like all the changes made in mod_perl 2.0, since is not so easy/fast to make the script working in the new mod_perl. And since I don't think that mod_perl is intuitive. mod_perl 1.0 isn't intuitive (the developers really need to learn some stuffs to use it), and mod_perl 2.0 is even more not intuitive.

This, of course, depends on your intuitions! mod_perl is different from CGI scripting. mod_perl 2.0 is different from mod_perl 1.0. It has to be to allow you to gain many of the advantages of having direct access to the Apache 2 environment, and to fix the lessons learned from the mod_perl 1.0 implementation.

If you're used to event-driven, multi-threaded client-server coding then the Apache 2 / mod_perl 2.0 model should make sense.

Personally I've not found my experience of mod_perl 2.0 any less intuitive that mod_perl 1.0. Do you have any specific examples in mind?

First, whe need to always return a constant for all the sub handlers. Well, on mod_perl 1.0 this is only an option.

Sorry, don't understand what you're getting at here...

2nd, a lot of methods are in different namespaces. Soo, we stay a long time testing the code and finding the new names or locations for the methods. mod_perl 2.0 has a module to help on that, but a little list in the docs of mod_perl 2.0 with the methods that were changed or doesn't exists any more will be good.

You mean like the Reference to mod_perl 1.0 to mod_perl 2.0 Migration :-)

The breaking up of the API into more modules and name spaces is a good think since the mod_perl 1.0 API was much to monolithic and hard to extend.

3rd, the output doesn't work like in CGI, where you just print to STDOUT. To get a good output you really need to call print() from the apache object: $apache->print(). We still have STDOUT, but will work strange for complex output flux. Also to flush, $|=1 doesn't work, you need to call rflush() for each flush.

It is hard to have simple STDOUT based output work in an environment where you can, for example, have an output stream that consists of open filehandles and pipes moving through filters that can arbitrarily buffer data running in an multi-threaded environment. Treating everything as a simple stream of characters just isn't practical in the general case.

Actually for CGI scripts is too hard to have them working on mod_perl 2.0. Is much better to rewrite them.

Of course it is. The same is true of mod_perl 1.0. If you don't rewrite your CGI scripts you're going to miss many of the advantages of the mod_perl environment.

That said, if you do just want to run CGI scripts under mod_perl 2.0 then ModPerl::RegistryBB, ModPerl::Registry and ModPerl::PerlRun should be all you need. If you're having problems with them then I'm sure that a polite message to the mod_perl list will get you some help.

Actually the biggest problem is that to use mod_perl 2.0 we have a lot of new things. For example, to test mod_perl 2.0 I was using Apache 2.0, Perl-5.8.1 and mod_perl 1.99. And for mod_perl 1.0 I was using Apache 1.3+, Perl-5.6.1 and mod_perl 1.29. Soo, the changes are not only in mod_perl, but in each chunk of software.

Since the reason mod_perl 2.0 exists is so we can take advantage of Apache 2.x features like filters and threading it's hardly surprising that you need to upgrade :-)

Soo, what the monks think about mod_perl 2.0? Are you using/testing it? How it's working?

Personally I'm not using it on any live sites at the moment since (IMHO) it's not yet ready for production work. The documentation hasn't been finished and I don't have the spare time to grok the source - as facinating as it looks.

I've played with a bit on dev boxes and am looking forward to some of it's features - it's going to make some Perl/Apache work a lot easier in the future.

For example, the ability to assign different Perl interpreters to different virtual hosts suddenly means that mod_perl becomes a much more attractive option for ISPs in shared hosting environments.

It sounds to me that the problems that you're encountering are just artefacts of the current incomplete state of the mod_perl 2.0 project. Once mod_perl 2.0 gets a point release out of the door I think many of your difficulties will disappear with the existence of improved documentation / features.

a lot of methods are in different namespaces.

It was mod_perl1's mistake to not be so modularized in the first place. mod_perl2 does a much better job of this.

the output doesn't work like in CGI, where you just print to STDOUT.

mod_perl coding != CGI coding. A more rigrious API, as opposed to STDIN/STDERR, should be considered a good thing. The best you can say about the CGI method is that it follows the Unix pipe model well. But what works so well for command lines doesn't work so well over networks. It's long past time that we move beyond this.

Also to flush, $|=1 doesn't work, you need to call rflush() for each flush.

Blame Perl for making a default global variable do autoflushing for every single file handle in your program (unless you localize it). Update: Oops, only does it for the currently selected filehandle. Thanks to chromatic for pointing this out.

Actually the biggest problem is that to use mod_perl 2.0 we have a lot of new things.

So you had to upgrade your Perl and Apache versions to get the biggest change in Perl-based web programming since mod_perl was first released? Seems a small price to pay.

If there is any problem with mod_perl2, it's that its documentation is lacking. Such as what you mentioned about converting to the new API.

I'm also very excited about its ProtocolHandlers. One of these days I'll have to get around to writing a Gopher handler.

Soo, what the monks think about mod_perl 2.0? Are you using/testing it? How it's working?

• Whatever function you use, add a use X::Y(); that is unrelated to the function itself.
• Try to find out what mistery function a use X::Y buyes you with perldoc X::Y is not working. So most is there, but useless since a user can not improve his skills. A module without doc is useless. I know the answer is somewhere but ... it can not be found.
• The namespace apache2 works in is the same namespace as apache1 but a module that works on ap1 does normaly not working under ap2.

  - If a module author bite in the table and support both version of ap one half of the users install a version for the wrong apache.

  - Using Apache::compat is no option: first it is not compatible, only most work and second it is slower so why using ap2 with breaks on?

  - A module that do a lot of work can not suround everything with if (MP2) { do this } else { do that }

Never forget, mod_perl 2 is not done yet. So not only is the coding not finished, but the documentation isnt either. Many of your points of frustration I think stem directly from those 2 facts. Patience is your best bet, it is a major upgrade (as is Apache 2.0 from 1.36).

Soo, what the monks think about mod_perl 2.0? Are you using/testing it? How it's working?

Since most other posters have addressed your individual points very well, I will leave that alone, and just tell you my personal experience with mod_perl 2.

I have been forced to use mod_perl 2 in a production environment for almost a year now. Normally I would never do this, but circumstances actually proved this to be the best option. Let me first explain those circumstances.

We created an application, which ran upon Windows 2000/Apache 1.36/mod_perl 1.0. It creates reports of arbitrary complexity for a database. It ran fine for almost a year, then due to details which I wont bore you with hear, the performance started to radically degrade. The problem is that mod_perl 1.0/Apache 1.36 on Windows is essentially a single-process, single-threaded application. Yes, thats right, a web/application server that can only serve ONE request at a time.

Now, we didn't know this getting into it, and Windows 2000 was not a choice, it was forced upon us. Our experience was with the Unix variants of mod_perl/Apache, it never occured to us that Windows would be all that different. As I said, it ran fine for almost a year, once it started to degrade, we started investigating. After a long discussion with the client (and a rather long unsuccessful attempt at convincing them to switch to Unix) we decided to investigate Apache 2/mod_perl 2 combo as a solution. The client understood the that Apache 2 (at the time) was still Beta, and mod_perl 2.0 was still in development.

We used Apache::compat, but soon choose to converted the nessecary code, and with minimal headache actually got it up and running. The worst part of it all was getting Apache 2.0/mod_perl 2.0 with SSL built and configured properly. We load tested the application, and found a signifigant improvement in the performance, and absolutely none of the performance degredation issue we had before.

Even though it was a beta Apache and mod_perl was still in active development, it was running better than the original, so we released it to production. I was really surprised, but nothing bad happened, everything worked fine. Only once did we have an issue, which turned out to be related more to DBI and Perl 5.8's threads. We fixed that issue in the code, and took the opportunity to upgrade Apache 2 to the released version, and mod_perl to its latest build.

Granted, we did not use any of the new mod_perl 2.0 bells and whistles, and our original app used handlers and not Apache::Registry. But it ported over easily, and has been running fine for almost a year now. In case anyone wondering, its load is not very high (about 20-30 concurrent users at any given time), but it is for a multi-national corporation, and used worldwide. Apparently they love it in the China office :-).

In general I am very impressed with mod_perl 2, in particular its performance Windows. I am very much looking forward to the upgrade, and can't wait for the new features (output filters, protocol handlers, etc etc etc) to be documented and finished. I think it has alot of serious potential.

One quick note, our original app was ported for another client to Unix with Apache 1.36/mod_perl 1.0 about a year and half ago, and has run without incident under the same (and sometimes worse) conditions as the original. *Sigh*, if only they hadn't been soo stuck on Windows.

The reason I dislike mod_perl has already been mentioned: lack of proper documentation. It's difficult to learn something when you have to google for how to do something new every 2 seconds. It'd be nice to have the documentation in hand.

I created a CGI::Application based cgi-script (a database frontend) which was originally running through the Xitami web server. It also works on Apache 2/mod_perl 1.99 as a ModPerl::Registry script without ANY changes to the code (the increased speed is just brilliant!)

The increased speed would be better still if you wrote that as true mod_perl.