Of course, I should have tried out print ref $r;, but my brain wouldn't allow me to see the obvious.

Ok, that proves that mod_perl is a bigger black box to me than I originally thought.

So, I guess the question I should be asking is: what is the best way to accomplish what I'm trying to do?

I'm beginning to believe that subclassing the request is not the best way to do it, as the $r object I've been passing around in every mod_perl project I've ever worked on is not, in fact, an Apache::Request.

If I do something like this:

sub handler{
 my $apr = shift;
 my $r = $apr->request;

 # Do something.
 return OK;
}
[download]

I can pass around my modified request object, but it will be an actual request rather than an instance of the Apache object.I still get an Apache object. Now that I've created my Apache::Request subclass, how do I use it?

Have any links to good articles discussing mod_perl internals that might be of assistance? I've gone beyond the books and links I know about, I'm affraid.

Thanks for the answer!

UPDATE: Struk out my wrongness.

I fail to see much difference between the two, actually. My subclassing example was taken from the Apache::Request man page under their subclassing section.

When I modified my Apache::Request object as was in the docs, it still broke exactly the same.

I guess I don't understand how I should be doing this. How do I get the server to return my new object instead of a generic Apache object. Or, how do I get the server to return my object blessed as an Apache object, instead of returning a generic Apache::Request object?

I'm even more confused now than when I started.

What you are failing to understand here is that your handler is not an object, it is just a class. In fact, it's not even called as class unless you tell mod_perl to use method handlers, which you haven't done here. In the examples in the docs, someone subclasses Apache::Request and then instantiates an object like this:

my $apr = My::Apache::Request::Subclass->new($r);
[download]

That is not what happens when mod_perl calls your handler. It doesn't call new, since new() is not a special method in Perl. It calls handler (well, you could tell it to call something else, but it's not important), passing an Apache::request object (note the lowercase r) as the only parameter. This object is normally referred to as $r, and it's the same thing you get by calling Apache->request().

At this point, you can create an Apache::Request object by passing $r to Apache::Request->new(), or instantiate a subclass of Apache::Request in the same way. You can even make it so that other people will get your subclass object when they call Apache->request() by calling it as a set method:

Apache->request($apr);
[download]

However, there is almost never a good reason to subclass Apache::Request and I don't understand why you think this will help with your session management woes. Apache::Request has nothing to do with session management. It only exists for the current request and nothing in it is saved when it goes away. So, please explain what you are really trying to do, and maybe I can suggest a better solution.

How do I get the server to return my new object instead of a generic Apache object. Or, how do I get the server to return my object blessed as an Apache object, instead of returning a generic Apache::Request object?

I think the short answer is, you can't/don't. No matter how hard you try, handler() will always receive a vanilla Apache object

So the next best thing would be to always start out your handlers like so:

  sub handler {
     my $r    = shift;
     my $my_r = My::Apache::Request->new($r);
     # do interesting things with $my_r
  }
[download]

Or perhaps you can create something like the Apache->instance() method, and do something like:

   # somewhere in your code...
   my $r = My::Apache::Request->instance;

   # in My::Apache::Request;
   package My::Apache::Request;
   use base qw(Apache::Singleton); # or something like it 

   sub _new_instance {
      my $class = shift;
      return $class->new(r => Apache::Request->instance);
   }
[download]

Thanks to everybody who's set my mind straight regarding mod_perl. I've discovered through this that subclassing the Apache::Handler isn't the best way to do this.

I'm going to go back and rearchitect some of the main application to give me this functionality. None of the "action" objects of the app are decdendant classes, and the constructor for each of the classes are exactly the same, so that's where I'll put the magic in.

I'll go back and write an "Action" object that the rest of the objects will use as a base class, and add methods to fiddle with the session for each object. The session will be passed to the constructor, as it is now, and I'll rewrite the per-object session manipulation to use new methods.

This will allow me to emulate private namespaces within the session transparently by having the parent Action object interrogate who the caller is and create a "private" and "public" namespace that the default methods will deal with.

All in all, it's not the solution I wanted, but I think it's the right one; Apache::Handler subclassing would have worked (if mod_perl worked the way I used to think it did :), but having application-type logic contained within the application, instead of the web server classes, makes for a more logical grouping of functions.

Thanks again, everybody! I never would have seen this path if you weren't so patient in explaining why my world view was wrong.