Re: Missing symbol: mod_perl2-RC3
Gordon Lack wrote: When I compile with MP_DEBUG=1 set the test reports this: 92021:/local/GML/install/apache2/bin/httpd: rld: Fatal Error: attempted access to unresolvable symbol in /local/GML//ServerUtil.so: Perl_Tstack_sp_ptr Please take a look at: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#_relocation_errors__or__undefined_symbol_ Is that the cause of the problem? No - it isn't. I know that because the good(?) news is that I've found out what the problem is. The symbol is in mod_perl.so, but is HIDDEN. This seems to be because it has been obtained from a static archive (libperl.a). [NOTE: This last statement could be completely wrong - I'm basing this on a quick perusal of man pages, not knowledge] The solution (*very* basic at present) is to tell the loader to export symbols from libperl.a which it would otherwise hide. To do this I fished out the loinker command which produced mod_perl.so and added a -exports option immediatley before -lperl (this option only affects the next load). Hardly a usable solution, but I'll see what I can do as far as automation goes... Yes, it means that irix is a special case and needs to add this option. So you have most of it solved. Now please take a look at perl_config_lddlflags in lib/Apache/Build.pm, it should probably go there (make a special case for IRIX). A patch would be gladly accepted. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Stas 99.9% of users do *not* need to use this workaround. So that Stas issue is moot if you ask me. Four out of my five biggest customers *will* need to have both modperl1 and modperl2 in the same Perl installation tree on their development machines, because they'll need to start looking at how to port their work over, and they won't want to duplicate-install all the other modules they use into two different Perl installations on one box. I would like to support Randal's contention (if not his tone) that indeed, in real-world mod_perl commercial situations that I'm familiar with (say about 8), 80% of those real-world users will want to have both mod_perl 1 and mod_perl 2 installed concurrently due to the generally-accepted production practice of if it ain't broke, don't fix it. By virtue of being actual mod_perl, they already have production mp1 installations. They will also want to be moving forward with leading, new releases for development of new systems, that is, mp2. In any case, Stas, I found myself frowning when you first put out that 99.9% not a problem number, and given the testaments given here, we can at least say everyone's just guessing what the real number is. Perhaps Randal should be thanking Stas for the potential conflicts, as it's fair to say that consulting fees can increase from confusions and complications arising from the mp1/mp2 transition. I do believe it's uncontested that with common configurations and proposals, simulataneous mp1 and mp2 installations will not be straightforward. People committed to mod_perl system will muddle through without doubt. New users won't generally see issues regardless of which docs they read. Though people who say extra hurdles don't help the community much have a point. On the gripping hand, I've never thought of mod_perl setup and administration as very intuitive or inherently robust. People who figure it out at all are generally already a notch or two above panders to the crowd here and have learned to read documentation. As a result of mod_perl's multi-step setup, I've long been very careful during new mod_perl setups. For a number of years now, I've been using private installation trees such that 0% of my commercial clients will have any mp1/2 issues as they use private, snapshotted installation trees to achieve high stability and service isolation. My modern installations if fact, generally use scripts which download, unpack, build, and install private installations of Apache, mod_perl, librequest, HTML::Mason, and even Perl itself with hundreds of modules from CPAN installed, all into a self-contained directory tree. Config files, log/state files, and the docroot(s) go outside this tree. Without revolutions in the mod_perl/Apache/CPAN space, this private installation approach is one of the few likely to provide really stable, isolated concurrent instances of mod_perl. It should be noted that mod_perl is not the only application server to suffer this problem, and the same things should be done for python 2.x, the Java multiverse, and PHP 4/5 web/SOA instances whenever availability, isolation, maintainability, and testability matter. Disk space is cheap. For my part, I'd put forth that one acceptance criteria of whatever mp2 release approach is adopted should be it should be hard to clobber an existing installation by being careless with an mp2 installation. Going forward, I'd ask the community to remain respectful, proposal and evidence-focused, with an eye rough consensus and working code. There have been both shining examples and dismal failures thus far in the discussion.
apr-ext test failure
I built fresh perl and apache. But mp2RC3 built is failing. I think it's due to some stupid point which I have failed to see. Help ! Pratik = /home/pratik/lab/perl/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /home/pratik/lab/perl/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -bugreport -verbose=1 t/apr-ext/bucket.t t/apr-ext/finfo.t t/apr-ext/pool.t t/apr-ext/table.t t/apr-ext/uri.t /home/pratik/lab/mp2/bin/httpd -d /home/pratik/lab/mod_perl-2.0.0-RC3/t -f /home/pratik/lab/mod_perl-2.0.0-RC3/t/conf/httpd.conf -D APACHE2 using Apache/2.0.52 (prefork MPM) waiting 120 seconds for server to start: . waiting 120 seconds for server to start: ok (waited 3 secs) server localhost.localdomain:8529 started server localhost.localdomain:8530 listening (filter_out_apache) server localhost.localdomain:8531 listening (TestModperl::merge) server localhost.localdomain:8532 listening (TestModperl::perl_options) server localhost.localdomain:8533 listening (TestModperl::setupenv) server localhost.localdomain:8534 listening (TestModules::proxy) server localhost.localdomain:8535 listening (TestUser::rewrite) server localhost.localdomain:8536 listening (TestVhost::log) server localhost.localdomain:8537 listening (TestVhost::config) server localhost.localdomain:8538 listening (TestProtocol::echo_bbs2) server localhost.localdomain:8539 listening (TestProtocol::echo_timeout) server localhost.localdomain:8540 listening (TestProtocol::echo_block) server localhost.localdomain:8541 listening (TestProtocol::echo_nonblock) server localhost.localdomain:8542 listening (TestProtocol::echo_bbs) server localhost.localdomain:8543 listening (TestProtocol::echo_filter) server localhost.localdomain:8544 listening (TestProtocol::pseudo_http) server localhost.localdomain:8545 listening (TestPreConnection::note) server localhost.localdomain:8546 listening (TestHooks::hookrun) server localhost.localdomain:8547 listening (TestHooks::startup) server localhost.localdomain:8548 listening (TestHooks::stacked_handlers2) server localhost.localdomain:8549 listening (TestHooks::trans) server localhost.localdomain:8550 listening (TestHooks::init) server localhost.localdomain:8551 listening (TestFilter::in_bbs_inject_header) server localhost.localdomain:8552 listening (TestFilter::both_str_con_add) server localhost.localdomain:8553 listening (TestFilter::in_str_msg) server localhost.localdomain:8554 listening (TestFilter::in_bbs_msg) server localhost.localdomain:8555 listening (TestDirective::perlmodule) server localhost.localdomain:8556 listening (TestDirective::perlrequire) server localhost.localdomain:8557 listening (TestDirective::perlloadmodule4) server localhost.localdomain:8558 listening (TestDirective::perlloadmodule3) server localhost.localdomain:8559 listening (TestDirective::perlloadmodule5) server localhost.localdomain:8560 listening (TestDirective::perlloadmodule6) t/apr-ext/bucket1..21 # Running under perl version 5.008006 for linux # Current time local: Mon Jan 10 23:00:45 2005 # Current time GMT: Mon Jan 10 17:30:45 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.20 # $b is defined ok 1 # $b ISA APR::Bucket object ok 2 # testing : type # expected: mod_perl SV bucket # received: mod_perl SV bucket ok 3 # testing : modperl b-length # expected: 6 # received: 6 ok 4 # testing : new($data, $offset)/buffer # expected: bartar # received: bartar ok 5 # testing : new($data, $offset)/len # expected: 6 # received: 6 ok 6 # testing : offset # expected: 3 # received: 3 ok 7 # testing : new($data, $offset, $len)/buffer # expected: bar # received: bar ok 8 # testing : new($data, $offse, $lent)/len # expected: 3 # received: 3 ok 9 # testing : new($data, $offset, $len_too_big) # expected: (?-xism:the length argument can't be bigger than the total) # received: APR::Bucket::new: the length argument can't be bigger than the total buffer length minus offset at /home/pratik/lab/mod_perl-2.0.0-RC3/t/lib/TestAPRlib/bucket.pm line 77. ok 10 # testing : data inside the bucket should get affected by the changes to the Perl variable it's created from # expected: AA # received: AA ok 11 # testing : new(PADTMP SV) # expected: [ # abcd, # ef, # ] # received: [ # abcd, # ef, # ] ok 12 # testing : new($data) # expected: xxx # received: xxx ok 13 ok 14 ok 15 ok 16 # testing : setaside status # expected: 0 # received: 0 ok 17 # testing : data inside the setaside bucket is unaffected by changes to the Perl variable it's created from # expected: AA # received: AA ok 18 ok 19 # testing : setaside status # expected: 0 # received: 0 ok 20 dubious Test returned status 0 (wstat 139, 0x8b) test program seems to have generated a core DIED. FAILED test 21 Failed 1/21 tests, 95.24% okay
Re: Overriding PerlAuthenHandler in sub-directories
Ferrari Geoffrey wrote:
Hi,
If I have activated a PerlAuthenHandler for a directory in httpd.conf with
Location /foo
...
PerlAuthenHandler My::Handler
/Location
How can I deactivate this PerlAuthenHandler for a subdirectory, such as
/foo/bar ?
if you want requests to /foo/bar to succeed unchecked then
Location /foo/bar
PerlAuthenHandler 'sub { return OK }'
/Location
should do the trick.
The online mod_perl docs explain that PerlHandlers can be deactivated
for subdirectories by setting PerlHandler default-handler (when
SetHandler has been set to perl-script), but either my problem lies
elsewhere, or it is not possible to have:
Location /foo/bar
PerlAuthenHandler default-handler # nor indeed
'PerlAuthenHandler none'
/Location.
default-handler is the default content handler (the one that sends a flat
file to your browser) so that's really not what you want (nor will it work :)
if what you _really_ want is apache's default auth checker use the example I
gave above but return DECLINED instead. OK will essentially turn off
authentication, while DECLINED will invoke .htpasswd-type checking.
you need to understand the mechanism here. the Requires directive is
enabling authentication for a given request, but there is no way to turn it
off once it has been enabled for a request, or to un-scope it within nested
configurations. so, what you need to do is use your PerlAuthenHandler to
control what happens next - either perform some authentication, allow apache
to perform some authentication, or perform none at all.
HTH
--Geoff
Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
I would like to support Randal's contention (if not his tone) that indeed, in real-world mod_perl commercial situations that I'm familiar with (say about 8), 80% of those real-world users will want to have both mod_perl 1 and mod_perl 2 installed concurrently due to the generally-accepted production practice of if it ain't broke, don't fix it. By virtue of being actual mod_perl, they already have production mp1 installations. They will also want to be moving forward with leading, new releases for development of new systems, that is, mp2. How difficult is it really to have two different perl installation !!?? It's a one time cost you have to pay for the principle - if it ain't broke, don't fix it. In fact - doing it actually applies that principle in practice. -Pratik -- http://hello:[EMAIL PROTECTED]
RE: MP2 - Make test Error - t/api/request_rec.t
Title: Re: MP2 - Make test Error - t/api/request_rec.t
Hey Stas,
Sorry, I have another
question/problem.
After building and installing MP2 and
Apache with no problems at all, I'm running into that problem where if I refresh
the page I may get what I want or I may get a previous page/request, even in
single user mode.
I'm having a hard time with this being a
scoping issue or something else with my code as its the same code that has been
running on mod_perl for over a year now on a different server, I didn't change a
thing when I brought it over.
Is there anything I could have done during
the apache and/or mod_perl builds to do this?
Thanks
-Chris
From: cfaust-dougot
[mailto:[EMAIL PROTECTED]Sent: Mon 1/10/2005 1:33 PMTo:
Stas BekmanCc: modperl@perl.apache.orgSubject: RE: MP2 -
Make test Error - t/api/request_rec.t
Thanks Stas, that did the
trick, test and install both ran without a problem!!
Thanks Again!
-Chris
From: Stas Bekman
[mailto:[EMAIL PROTECTED]Sent: Mon 1/10/2005 11:17 AMTo:
cfaust-dougotCc: modperl@perl.apache.orgSubject: Re: MP2 -
Make test Error - t/api/request_rec.t
Chris Faust wrote: Hi Stas, Moving to a
new server and I'm rebuilding everything from scratch, I'm getting a
single error during "make test" for "t/api/request_rec.t". Didn't find
much info on it, saw a message from you to Ruslan Zakirov which had the
error but the email was for a different problem. # testing :
$r-hostname # expected: TAGTEAM-ES3 # received:
tagteam-es3 not ok 14This patch should fix it,
Chris:Index:
t/response/TestAPI/request_rec.pm===---
t/response/TestAPI/request_rec.pm (revision 124805)+++
t/response/TestAPI/request_rec.pm (working copy)@@ -60,7 +60,7
@@ # HTTP
1.0 ok t_cmp $r-proto_num, 1000,
't-proto_num';- ok t_cmp $r-hostname,
$r-get_server_name, '$r-hostname';+ ok t_cmp
lc($r-hostname), lc($r-get_server_name),
'$r-hostname';
{ my $old_hostname =
$r-hostname("other.hostname");--__Stas
Bekman JAm_pH
-- Just Another mod_perl Hackerhttp://stason.org/
mod_perl Guide --- http://perl.apache.orgmailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.comhttp://modperlbook.org http://apache.org http://ticketmaster.com
Apache::Test autogenerated request parts
Hi, I have 2 files t/response/TestSession/7uaexceptionfile.pm and t/session/7uaexceptionfile.t. t/TEST t/session/7uaexceptionfile.t works as expected but t/TEST -configure overwrites my handcrafted t/session/7uaexceptionfile.t. Why is that so? Torsten pgpUr0z9lx6PB.pgp Description: PGP signature
Re: Apache::Test autogenerated request parts
Torsten Foertsch wrote: Hi, I have 2 files t/response/TestSession/7uaexceptionfile.pm and t/session/7uaexceptionfile.t. t/TEST t/session/7uaexceptionfile.t works as expected but t/TEST -configure overwrites my handcrafted t/session/7uaexceptionfile.t. Why is that so? probably because it thinks it was autocreated - I suspect it created it initially, before you went and wrote it yourself. try running t/TEST -clean _then_ adding your hand-crafted .t file _then_ running t/TEST -config. t/TEST -config should see that the file was there already and not overwrite it. HTH --Geoff
Re: Bug(?) in mod_perl-2 RC3
Web servers itself starts spinning on 100% CPU once this happens.
Log has this entry:
[Thu Jan 06 18:52:18 2005] [error] APR::Socket::recv:
(11) Resource temporarily unavailable at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_block.pm
line 41
I suppose that's t/protocol/echo_block.t (and not t/protocol/echo_filter),
right?
No - the test output at this stage looks like this:
t/protocol/echo_block...# Failed test 3 in
t/protocol/echo_block.t at line 22 fail #2
FAILED test 3
Failed 1/3 tests, 66.67% okay
t/protocol/echo_filter..
(there no no newline on that last line.)
Wow, irix. It's a first time I see anybody trying modperl on it.
Really? I've had it running v1.25 on Apache1.3.x for years.
Can you identify where the process spins? e.g. try the technique explained
in: 21.7.4.1. Using the Perl trace
http://modperlbook.org/html/ch21_07.html or some tracing tool.
any difference if you put an eval {} block around that line?
Well, I doubt it will make much difference given that it was reported for a
different script.
It all seems to be pointing to issues around (non-)blocking sockets? The
echo_block and echo_filter tests both refer to fixes on Apache2.0.52 for
Open/NetBSD here.
Anyway - here's what you requested (after adding t/conf/modperl_extra.pl):
I removed all of the dirs (expect lib) from t which preceded protocol then
ran make test. This is the resulting log (I've wrapped some bits, but the
longer lines may still wrap...).
=
[Mon Jan 10 17:52:05 2005] [info]
Init: Initializing OpenSSL library
[Mon Jan 10 17:52:05 2005] [info]
Init: Seeding PRNG with 0 bytes of entropy
[Mon Jan 10 17:52:05 2005] [info]
Init: Generating temporary RSA private keys (512/1024 bits)
[Mon Jan 10 17:52:06 2005] [info]
Init: Generating temporary DH parameters (512/1024 bits)
[Mon Jan 10 17:52:06 2005] [warn]
Init: Session Cache is not configured [hint: SSLSessionCache]
[Mon Jan 10 17:52:06 2005] [info]
Init: Initializing (virtual) servers for SSL
[Mon Jan 10 17:52:06 2005] [info]
Server: Apache/2.0.52, Interface: mod_ssl/2.0.52, Library: OpenSSL/0.9.7d
[Mon Jan 10 17:52:06 2005] [info]
Init: Initializing OpenSSL library
[Mon Jan 10 17:52:06 2005] [info]
Init: Seeding PRNG with 0 bytes of entropy
[Mon Jan 10 17:52:06 2005] [info]
Init: Generating temporary RSA private keys (512/1024 bits)
[Mon Jan 10 17:52:07 2005] [info]
Init: Generating temporary DH parameters (512/1024 bits)
[Mon Jan 10 17:52:07 2005] [info]
Init: Initializing (virtual) servers for SSL
[Mon Jan 10 17:52:07 2005] [info]
Server: Apache/2.0.52, Interface: mod_ssl/2.0.52, Library: OpenSSL/0.9.7d
[Mon Jan 10 17:52:07 2005] [notice]
Digest: generating secret for digest authentication ...
[Mon Jan 10 17:52:07 2005] [notice]
Digest: done
[Mon Jan 10 17:52:07 2005] [notice]
Apache/2.0.52 (Unix) DAV/2 mod_ssl/2.0.52 OpenSSL/0.9.7d
mod_perl/1.999.20 Perl/v5.8.5 configured -- resuming normal operations
[Mon Jan 10 17:52:07 2005] [info]
Server built: Jan 6 2005 14:00:24
[Mon Jan 10 17:52:07 2005] [debug]
prefork.c(955): AcceptMutex: sysvsem (default: sysvsem)
[Mon Jan 10 17:52:16 2005] [error]
recv() has returned untainted data:
at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_block.pm
line 38.\n
[Mon Jan 10 17:52:41 2005] [error]
Caught SIGUSR2! at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/conf/modperl_extra.pl line 6
Book::Startup::__ANON__('USR2')
called at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_filter.pm
line 22
eval {...} called at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_filter.pm
line 22
TestProtocol::echo_filter::uc_filter('Apache::Filter=SCALAR(0x102b00d0)',
'APR::Brigade=SCALAR(0x102b0100)') called at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_filter.pm
line 50
eval {...} called at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_filter.pm
line 50
TestProtocol::echo_filter::handler('Apache::Connection=SCALAR(0x101ab0c8)')
called at -e line 0
eval {...} called at -e line 0
[Mon Jan 10 17:52:41 2005] [error]
Apache::Filter::fflush: (500) Block not fully transferred at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/echo_filter.pm
line 50
[Mon Jan 10 17:52:50 2005] [error]
APR::Socket::recv: (11) Resource temporarily unavailable at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/pseudo_http.pm
line 118
[Mon Jan 10 17:52:50 2005] [error]
APR::Socket::recv: (11) Resource temporarily unavailable at
/local/GML/Apache2/mod_perl-2.0.0-RC3/t/protocol/TestProtocol/pseudo_http.pm
line 118
*** The following error entry is expected and harmless ***
Re: Missing symbol: mod_perl2-RC3
Yes, it means that irix is a special case and needs to add this option. So
you have most of it solved. Now please take a look at
perl_config_lddlflags in lib/Apache/Build.pm, it should probably go there
(make a special case for IRIX). A patch would be gladly accepted.
It's ldopts() that needs the code.
Here is a patch. Tested on irix. Added option at correct place.
--- Build.pm.orig Thu Jan 6 00:46:49 2005
+++ Build.pmMon Jan 10 18:28:58 2005
@@ -442,6 +442,16 @@
$config-{ldflags} = $ldflags; #reset
+# Iff we are on Irix then we need to persuade the symbols in libperl.a
+# to not be HIDDEN once we load them into mod_perl.so. So we need to
+# add -exports immediately before -lperl.
+# This assumes we need this for all irix builds.
+#
+if ($^O eq 'irix') {
+ warn Failed to fix Irix symbol exporting\n unless
+($ldopts =~ s/-lperl\b/-exports -lperl/);
+}
+
$ldopts;
}
Re: MP2 - Make test Error - t/api/request_rec.t
cfaust-dougot wrote: Thanks Stas, that did the trick, test and install both ran without a problem!! Thanks Chris. Now committed. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: MP2 - Make test Error - t/api/request_rec.t
[please don't forget to trim unrelated stuff from your messages, and please start new questions in a new thread, rather than reply to an unrelated thing. thanks.] After building and installing MP2 and Apache with no problems at all, I'm running into that problem where if I refresh the page I may get what I want or I may get a previous page/request, even in single user mode. I'm having a hard time with this being a scoping issue or something else with my code as its the same code that has been running on mod_perl for over a year now on a different server, I didn't change a thing when I brought it over. Is there anything I could have done during the apache and/or mod_perl builds to do this? sorry, I have no idea. If you reduce your code to a simple few-lines script/handler and post it here, I'm sure someone will figure out what the problem is, and whether it's an issue with your code or a bug in mp2. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: MP2 - Make test Error - t/api/request_rec.t
Title: Re: MP2 - Make test Error - t/api/request_rec.t
sorry, I have no idea. If you reduce your
code to a simple few-lines script/handler and post it here, I'm sure
someone will figure out what the problem is, and whether it's an
issue with your code or a bug in mp2.
Thanks Stas, I'll take all the help I can get... I've
been trying to figure this out all day without any luck, I thought I could put
to rest any problems with code once I went with a content handler and put
everything in a subdirectory so I could be sure I don't have any messy global
values.
This code has been working on a previous server with
no problems, we are moving to a new server and this is the result of the same
code but after a new apache and mod_perl install.
In short I can sit there and refresh the same page and
over and over, sometimes I get the right page, other times I get other
pages
Thanks in Advance!
-Chris
Below are the basics:
Index.pm:
package MALDEN::scripts::Index;use Apache::Const
-compile = qw(:common REDIRECT OK);
use strict;use Mail::Sendmail;use
XML::RSS;use POSIX qw(strftime);use vars qw($db $r $CGI $user_name
$user_role);
###
Main# Our Mod_Perl Content Handlersub handler {$r =
shift;
# Define our root HTML template
path$ENV{'HTML_TEMPLATE_ROOT'} =
"/websites/MALDEN/templates";
# Create a new global CGI object$CGI =
new CGI();
# Create a global DB connection$db =
TOOLS::PublicConnectDB-connect_to_db();#
Authenticateauth_incoming_user();
# Determine what we want to do based on the
request# Most functions will return "OK" after the "display page"
subroutine# but for those that we have to redirect, the redirect
directive and the URL will be returned my $back_url =
"";my $request_type = "";($request_type,$back_url) =
determine_proper_action();# Properly Exit the Handler from
all subs within Determine Proper Actionif ($request_type eq
'Apache::REDIRECT') {$r-headers_out-set(Location =
$back_url); return
Apache::REDIRECT;} else {return
Apache::OK;}} # End of
Sub##
And its defined in apache as
VirtualHost :80
.
PerlModule MALDEN::scripts::IndexLocation
"/index" SetHandler
perl-script PerlHandler
MALDEN::scripts::Index/Location
.
/VirtualHost
Re: MP2 - Make test Error - t/api/request_rec.t
cfaust-dougot wrote:
sorry, I have no idea. If you reduce your code to a simple few-lines
script/handler and post it here, I'm sure someone will figure out what the
problem is, and whether it's an issue with your code or a bug in mp2.
Thanks Stas, I'll take all the help I can get... I've been trying to figure this out all day without any luck, I thought I could put to rest any problems with code once I went with a content handler and put everything in a subdirectory so I could be sure I don't have any messy global values.
This code has been working on a previous server with no problems, we are moving to a new server and this is the result of the same code but after a new apache and mod_perl install.
In short I can sit there and refresh the same page and over and over, sometimes I get the right page, other times I get other pages
Thanks in Advance!
-Chris
Below are the basics:
Index.pm:
package MALDEN::scripts::Index;
use Apache::Const -compile = qw(:common REDIRECT OK);
use strict;
use Mail::Sendmail;
use XML::RSS;
use POSIX qw(strftime);
use vars qw($db $r $CGI $user_name $user_role);
##
# Main
# Our Mod_Perl Content Handler
sub handler {
$r = shift;
# Define our root HTML template path
$ENV{'HTML_TEMPLATE_ROOT'} = /websites/MALDEN/templates;
# Create a new global CGI object
$CGI = new CGI();
# Create a global DB connection
$db = TOOLS::PublicConnectDB-connect_to_db();
# Authenticate
auth_incoming_user();
# Determine what we want to do based on the request
# Most functions will return OK after the display page subroutine
# but for those that we have to redirect, the redirect directive and the URL will be returned
my $back_url = ;
my $request_type = ;
($request_type,$back_url) = determine_proper_action();
# Properly Exit the Handler from all subs within Determine Proper Action
if ($request_type eq 'Apache::REDIRECT') {
$r-headers_out-set(Location = $back_url);
return Apache::REDIRECT;
} else {
return Apache::OK;
}
} # End of Sub
You realize that this is not an a-few-lines-test-case. How can we analyze
or run it if it requires a database connection and non-existing
auth_incoming_user and other functions. Please reduce it to the case that
has no external dependencies and so that it still fails. I bet while you
are reducing that you will find the problematic code.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: MP2 - Make test Error - t/api/request_rec.t
Title: Re: MP2 - Make test Error - t/api/request_rec.t You realize that this is not an a-few-lines-test-case. How can we analyzeor run it if it requires a database connection and non-existingauth_incoming_user and other functions. Please reduce it to the case thathas no external dependencies and so that it still fails. I bet while youare reducing that you will find the problematic code.Sorry, I know its unrunable as it is, I was just hoping that showing it was a package and everything was called with a subroutine that I could have eliminated any problems with global values or anything of that nature- I'll try to do something to produce the same results without all the overhead. -Chris
Re: Comments on the document 'Installing mod_perl 2.0'
d) Another useful tip - that may seem a bit stupid, but which I found useful - was to check after completing the installation process that the 'modules' directory under '/usr/local/apache2' (or whatever) contained the file 'mod_perl.so'. In my first few attempts at installation this was useful to see if things had actually been installed in the right place. I'm not sure I'm following this one. Did you have a case that it wasn't installed there? Yes... I'm trying to recall the details but I think it was because I had set the MP_AP_PREFIX= to the wrong location (...my earlier comment about not understanding what it should be set to!). The install said completed without coughing, and when I looked hopefully in the /modules/ directory of the Apache installation tree the 'mod_perl.so' was absent. So I used that method to check whether I was at least on the right track with the installation. I tried it a couple of times before I realised what I might be doing wrong... =)
svn commit: r124806 - /perl/modperl/trunk/Changes
Author: stas Date: Mon Jan 10 08:09:26 2005 New Revision: 124806 URL: http://svn.apache.org/viewcvs?view=revrev=124806 Log: log the last fix by joes Modified: perl/modperl/trunk/Changes Modified: perl/modperl/trunk/Changes Url: http://svn.apache.org/viewcvs/perl/modperl/trunk/Changes?view=diffrev=124806p1=perl/modperl/trunk/Changesr1=124805p2=perl/modperl/trunk/Changesr2=124806 == --- perl/modperl/trunk/Changes (original) +++ perl/modperl/trunk/Changes Mon Jan 10 08:09:26 2005 @@ -12,6 +12,9 @@ =item 1.999_21-dev +pool arguments to startup and connection callbacks must be blessed +into APR::Pool and not Apache::Pool class [joes] + Make PerlSetEnv, PerlPassEnv and %ENV in PerlRequre, PerlModule, PerlConfigRequire and PerlPostConfigRequire affect each, so a change in one of these immediately seen in the others. [Pratik pratiknaik
svn commit: r124811 - /perl/modperl/trunk/lib/ModPerl/TestRun.pm
Author: stas
Date: Mon Jan 10 08:27:30 2005
New Revision: 124811
URL: http://svn.apache.org/viewcvs?view=revrev=124811
Log:
it's not mod_fastcgi.c but usually mod_fastcgi-xx.yy.c so use regex in
autoconfig_skip_module_add
Modified:
perl/modperl/trunk/lib/ModPerl/TestRun.pm
Modified: perl/modperl/trunk/lib/ModPerl/TestRun.pm
Url:
http://svn.apache.org/viewcvs/perl/modperl/trunk/lib/ModPerl/TestRun.pm?view=diffrev=124811p1=perl/modperl/trunk/lib/ModPerl/TestRun.pmr1=124810p2=perl/modperl/trunk/lib/ModPerl/TestRun.pmr2=124811
==
--- perl/modperl/trunk/lib/ModPerl/TestRun.pm (original)
+++ perl/modperl/trunk/lib/ModPerl/TestRun.pm Mon Jan 10 08:27:30 2005
@@ -64,12 +64,9 @@
# - don't inherit LoadModule perl_module from the apache httpd.conf
# - loaded fastcgi crashes some mp2 tests
-my %skip = map { (mod_$_.c = 1) } qw(perl fastcgi);
-sub should_skip_module {
-my($self, $name) = @_;
+my @skip = ('mod_perl.c', qr/mod_fastcgi.*?\.c$/);
-exists $skip{$name} ? 1 : $self-SUPER::should_skip_module($name);
-}
+Apache::TestConfig::autoconfig_skip_module_add(@skip);
1;
svn commit: r124832 - /perl/modperl/trunk/t/response/TestAPI/request_rec.pm
Author: stas
Date: Mon Jan 10 13:38:31 2005
New Revision: 124832
URL: http://svn.apache.org/viewcvs?view=revrev=124832
Log:
some hostnames are set to upcase
Modified:
perl/modperl/trunk/t/response/TestAPI/request_rec.pm
Modified: perl/modperl/trunk/t/response/TestAPI/request_rec.pm
Url:
http://svn.apache.org/viewcvs/perl/modperl/trunk/t/response/TestAPI/request_rec.pm?view=diffrev=124832p1=perl/modperl/trunk/t/response/TestAPI/request_rec.pmr1=124831p2=perl/modperl/trunk/t/response/TestAPI/request_rec.pmr2=124832
==
--- perl/modperl/trunk/t/response/TestAPI/request_rec.pm(original)
+++ perl/modperl/trunk/t/response/TestAPI/request_rec.pmMon Jan 10
13:38:31 2005
@@ -60,7 +60,7 @@
# HTTP 1.0
ok t_cmp $r-proto_num, 1000, 't-proto_num';
-ok t_cmp $r-hostname, $r-get_server_name, '$r-hostname';
+ok t_cmp lc($r-hostname), lc($r-get_server_name), '$r-hostname';
{
my $old_hostname = $r-hostname(other.hostname);
svn commit: r124834 - /perl/modperl/trunk/lib/Apache/Build.pm
Author: stas
Date: Mon Jan 10 13:55:30 2005
New Revision: 124834
URL: http://svn.apache.org/viewcvs?view=revrev=124834
Log:
layout tweaks
Modified:
perl/modperl/trunk/lib/Apache/Build.pm
Modified: perl/modperl/trunk/lib/Apache/Build.pm
Url:
http://svn.apache.org/viewcvs/perl/modperl/trunk/lib/Apache/Build.pm?view=diffrev=124834p1=perl/modperl/trunk/lib/Apache/Build.pmr1=124833p2=perl/modperl/trunk/lib/Apache/Build.pmr2=124834
==
--- perl/modperl/trunk/lib/Apache/Build.pm (original)
+++ perl/modperl/trunk/lib/Apache/Build.pm Mon Jan 10 13:55:30 2005
@@ -26,12 +26,12 @@
use constant IS_MOD_PERL_BUILD = grep { -e $_/lib/mod_perl.pm } qw(. ..);
-use constant AIX= $^O eq 'aix';
-use constant DARWIN = $^O eq 'darwin';
+use constant AIX = $^O eq 'aix';
+use constant DARWIN = $^O eq 'darwin';
use constant IRIX= $^O eq 'irix';
-use constant HPUX = $^O eq 'hpux';
+use constant HPUX= $^O eq 'hpux';
use constant OPENBSD = $^O eq 'openbsd';
-use constant WIN32 = $^O eq 'MSWin32';
+use constant WIN32 = $^O eq 'MSWin32';
use constant MSVC = WIN32() ($Config{cc} eq 'cl');
@@ -773,7 +773,7 @@
my $class = shift;
my $self = bless {
-cwd = Cwd::fastcwd(),
+cwd= Cwd::fastcwd(),
MP_LIBNAME = 'mod_perl',
@_,
}, $class;
@@ -789,8 +789,8 @@
my %default_files = (
'build_config' = 'lib/Apache/BuildConfig.pm',
-'ldopts' = 'src/modules/perl/ldopts',
-'makefile' = 'src/modules/perl/Makefile',
+'ldopts' = 'src/modules/perl/ldopts',
+'makefile' = 'src/modules/perl/Makefile',
);
sub clean_files {
