Perrin responded to my question below. His response works with what I'm
trying to do. Let me know if you think this is a bad idea.
On Tue, 2005-08-16 at 09:20 -0700, Justin Luster wrote:
> The way it relates is that in the previous code I was doing this:
>
> my $r = Apache->request;
>
> $r->content_type('text/html');
>
> It seems that in Mod_Perl 2.0 this does not work.
It has changed to this:
Apache2::RequestUtil->request()
And you need to set this in your conf:
PerlOptions +GlobalRequest
Read the porting guide:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_r
equest_
> From
> the documentation that I read it seems that Mod_Perl wraps up my
> main.pl code into a "handler()" function. The documentation then
> describes that it passes the ApacheObj as the 1st parameter to this
> function.
That's correct, you can get it that way.
> So by
> doing this:
>
> my $ModPerlObj = @_[0];
>
> I'm able to get that ApacheObj and pass it to my code. I don't think
> that I need it to be different for each request.
No, you really do. When you create a closure, it keeps the first
request that comes in and you will never be setting the content-type on
any request after that. I expect it will fail and possibly cause memory
problems. All you need to do to fix your code is to pass $r instead of
making a closure:
use strict;
use warnings;
my $r = shift;
main::start($r);
package main;
sub start {
my $r = shift;
authlib::Initialize($r);
}
I'm not sure it's worth having the separate sub at all though, if that's
all that's in it.
> We ship our code out to clients throughout the world. Because of this
> our code could be run on any type of Mod_Perl system. So it would be
> nice to find a method that would work with anything out there. It is
> frustrating that something as simple as this could not stay consistent
> across versions.
You can't really expect your code to work on beta pre-release versions.
People need to keep up to some degree if they want to use unstable code.
The 2.0 release is stable, and the 1.x series is stable. Pre-release
versions of 2.0 are totally unsupported.
> We generally do not rely on outside Perl libraries. We try to keep
> all of the code that our clients need wrapped up in our Perl files.
> This way we are not relying on the end computer as much.
We do this too, by packaging all of the CPAN modules we use in a bundle
that we compile and access locally, not from site_perl.
> Sorry, I'm not the "Musician's Friend" but I'm still a nice guy :)
I remember your winning photo from last year. This year's was not as
good.
- Perrin
-----Original Message-----
From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 10:36 AM
To: Justin Luster
Cc: modperl@perl.apache.org
Subject: Re: Mod_Perl 2.0 Header question
>I find that this breaks under some versions of Mod_Perl 2.0. I'm
>working with two older versions: 1.99_07-dev and 1.99_12 both on Linux
>machines.
You should really try to use at least RC 5+
> My confusion is how to send the proper 2.0 header. In my in-house
> version Apache->request; does not seem to work. The 2.0 documentation
> says use Apache2::RequestUtil but that does not work either. My
clients
> version however works with Apache->request and I'm confused as to why.
Apache2::RequestUtil doesn't exist in the versions you mentioned. Its
still called Apache::RequestUtil.
http://perl.apache.org/docs/2.0/rename.html
To answer your question though, I believe you could do something like
this, *untested*
unless ($ENV{GATEWAY_INTERFACE} =~ /Perl/) {
## CGI script or commandline
if ($ENV{GATEWAY_INTERFACE} =~ /CGI/) {
## CGI
}
else {
## Commandline
}
}
elsif ($ENV{MOD_PERL_API_VERSION} == 2) {
## mod_perl 2 RC 5 +
}
elsif (eval { require mod_perl } && $mod_perl::VERSION > 1.99) {
## mod_perl 1.9900 -> 1.99022 which is RC4
}
elsif ( $mod_perl::VERSION < 1.99) {
## mod_perl 1.x
}
else {
## fatal error .. I don't think this will get hit
}
Also, to send content headers in at least mp2, you should be using
i.e.
$r->content_header('text/html');
END
------------------------------------------------------------
What doesn't kill us can only make us stronger.
Nothing is impossible.
Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
http://www.liquidation.com
http://www.uksurplus.com
http://www.govliquidation.com
http://www.gowholesale.com
