Geoffrey Young gave a cool talk on this at ApacheCon this week, going over his frustration in moving from mod_perl 1.x to 2.x and how much he liked it once he understood the reasoning. While it's a bit harder to follow without the audio, the slides do point out several pitfalls.

One other nugget was Apache2::porting, which can help you find the functionality which has moved.

Sidebar: I have in my notes a chunk of Apache2/mod_perl2 code he showed off which handled filtering outbound HTML and wrote next to it: solves the absolute URL problem on perlmonks!. One could just filter the outgoing HTML to strip absolute "http://*perlmonks*/" cruft out of outbound posts.

To transform your CGI-registry scripts into real handlers is easy (p. 38 of the above book):

• Wrap the code that was previously in your registry script into a handler subroutine.
• Add a statement that returns the status to the server when the subroutine has succesfully completed.
• Add a package declaration to the top of the code.
• Wrap it all up in a module (and do not forget to end the module with a '1').

Ok. Once I wrap my stuff, how do I get the parameters from GET? How do I build a new URI from an existing one, changing only one or two params? I've read through some 500 pages in the past two days and I'm getting nowhere. I know tons about how to secure a mod_perl server, but I can't find out how to USE the bloody thing!

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

OK, I see your point.

Without having tried it myself (I lack the time now), it seems you can replace CGI.pm by Apache::Request.

The only change to your script is how you instantiate the request-object into a CGI-compatible object:

use Apache::RequestRec;
sub handler {
   my $r=shift;
   my $req = Apache::RequestRec->new($r);
   ...
}
[download]

$req will now act as a CGI-object and all well-known CGI-methods for getting and setting the GET and POST parameters (as they are implemented in Apache::RequestRec) can be used.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Ok. Once I wrap my stuff, how do I get the parameters from GET? How do I build a new URI from an existing one, changing only one or two params? I've read through some 500 pages in the past two days and I'm getting nowhere. I know tons about how to secure a mod_perl server, but I can't find out how to USE the bloody thing!

Walk away. Seriously, just walk away for a few hours/days. This stench of despair is not good. http://perl.apache.org/docs/2.0/user/coding/cooking.html

 use CGI::Cookie ();
  use Apache::RequestRec ();
  use APR::Table ();
  
  use Apache::Const -compile => qw(REDIRECT);
  
  my $location = "http://example.com/final_destination/";
  
  sub handler {
      my $r = shift;
  
      my $cookie = CGI::Cookie->new(-name  => 'mod_perl',
                                    -value => 'awesome');
  
      $r->err_headers_out->add('Set-Cookie' => $cookie);
      $r->headers_out->set(Location => $location);
      $r->status(Apache::REDIRECT);
  
      return Apache::REDIRECT;
  }
  1;
[download]

The first argument to your handler is a Apache::RequestRec object. Now go read some documentation to see what you get with Apache::RequestRec.

http://perl.apache.org/docs/2.0/user/index.html and I cannot seem to find the answers to these questions.

You need to read Part III Part IV and Part V of the user documentation. If you're in a rush, grab yourself a recipee.

There are a few things about mod_perl 2 that you should know. First and foremost: Apache::Request doesn't work with mod_perl 1.99 yet. You can directly use $r if you so wish. $r->hostname, $r->get_server_port, $r->uri, and $r->args can be very helpful if you wish to get the current URI. However, you'll need to add quite a bit of code to get the same functionality as either Apache::Request or CGI. You can use CGI as long as you use Apache::compat.

In all, I wouldn't suggest migrating to mod_perl 1.99 yet. The documentation is sparse and there are still a few bugs. Still checking out mod_perl 1.99_11 to see if some of my concerns are still there. I hope this helps you with your problem.

This is a completely new web app, so would you recommend using modperl 1.x right now, then migrating to MP2 when it comes out?

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

modperl 1.x will be around for a long time. It makes a lot of sense to use that now and migrate to version 2 when the latter has stabilised :)

Yes, I am telling you to wait for the time being and instead go with mod_perl 1.x. If you take a gander at the API documentation and run through some of the modules, you might notice that some of them are less than complete. I'm not saying that I dislike MP2 at this point. I'm saying that in order to get a feel for the entire API you either have to read an assload of source code or pay 99 cents a minute talking to the Psychic Friends Network getting yes/no/vaguely detailed answers to API questions (pricey, but definitely very entertaining...I never knew that APR::Table had a spirit that wishes for me to release it. No lies. Ask antirice). I'm certainly excited about MP2. I like the control that Apache 2.0 seems to offer. Unfortunately, it just isn't there yet. I have a couple of document servers running on our intranet with Apache 2 using a mod_perl handler to check for authentication and whatnot in an attempt to get a feel for the new way of doing everything (ok, not everything but things like args parsing in list context(ok, multi value didn't work) doesn't work the same and send_cgi_header is gone). I've already started to develop libraries (mostly by stealing chunks from CGI.pm) that work outside of Apache::compat however it's mostly a side project. It'll have to wait until antirice and I finish with our HTML::Template extension modules.

You can use CGI as long as you use Apache::compat.

Are you sure about this? According to the porting docs you can use CGI.pm with mod_perl2 as long as you use version 2.93 or greater.

CGI.pm is capable of taking the apache request object so it can deal with any mod_perl specific issues (like cleaning up globals) that need to be done. The more people that try it, the quicker it will be release quality.

my $r = Apache->request;
my $query = CGI->new($r);
[download]

Note that to get access to the Apache->request object you may need to activate 'PerlOptions +GlobalRequest' in your apache config.

Also, the Apache::Request module for mod_perl2 is coming along nicely. Although it is not quite ready for production, I don't think it will be much longer.

- Cees

The only issue of which I am aware that had me use Apache::compat deals with CGI.pm's header subroutine. Since it uses $r->send_cgi_header. According to the docs, send_cgi_header is not available under mod_perl2. Am I incorrect in my interpretation? If so, I am quite sorry. If not then I apologize for not mentioning it earlier.

not sure how much help this will be but i recently put up an Apache2 server (for Subversion) and wasn't sure if mod_perl (for Apache2) was quite ready for real world use. a bit of browsing later and i instead went with FastCGI.

use CGI::Fast qw( :standard );

while (my $q = new CGI::Fast) {
    process_request($q);
}
[download]

presto, script now way fast without mod_perl. there are some configuration directives that seem to imply that FastCGI can handle Auth stuff as well.

Simply use ModPerl::Registry as your handler (basically Apache::Registry for mod_perl2) and be done with it without changing your script at all (given that it is Apache::Registry compatible, that is no __END__ section ... easy).

Because I will be using the request/response chain in the near future. I want to do a lot of filtering of input and output and I need my stuff to be in handlers in the first place. (At least, that's my understanding.)

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

I want to do a lot of filtering of input and output and I need my stuff to be in handlers in the first place.

I don't think that is necesary anymore. The filtering stuff is much more powerful in mod_perl2 (mainly because of the underlying changes to Apache2).

In mod_perl1 you could only filter responses generated in mod_perl with a mod_perl filter (using Apache::Filter or one of the other chaining modules).

In mod_perl2, you can write a filter in perl that can parse the output of any other apache module. In fact, mod_include is now also written specifically as a filter. So as an example, you could have a Java servlet whose output is filtered though mod_include, and then filtered again through a mod_perl2 filter.

See the mod_perl2 Filter docs for more info.