cvs commit: modperl-2.0/t/response/TestApache compat2.pm
stas2002/06/26 09:16:58
Modified:t/response/TestApache compat2.pm
Log:
add Apache-module compat tests
Revision ChangesPath
1.19 +9 -1 modperl-2.0/t/response/TestApache/compat2.pm
Index: compat2.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestApache/compat2.pm,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- compat2.pm4 Jun 2002 13:04:47 - 1.18
+++ compat2.pm26 Jun 2002 16:16:58 - 1.19
-24,15 +24,23
sub handler {
my $r = shift;
-plan $r, tests = 48;
+plan $r, tests = 50;
$r-send_http_header('text/plain');
my $cfg = Apache::Test::config();
my $vars = $cfg-{vars};
+### Apache- tests
my $fh = Apache-gensym;
ok t_cmp('GLOB', ref($fh), Apache-gensym);
+
+ok t_cmp(1, Apache-module('mod_perl.c'),
+ Apache::module('mod_perl.c'));
+ok t_cmp(0, Apache-module('mod_ne_exists.c'),
+ Apache::module('mod_ne_exists.c'));
+
+### $r- tests
# test header_in and header_out
# and err_header_out
Re: errors installing libapreq
Try an older version. --- Tim Bolin [EMAIL PROTECTED] wrote: ok, im at the end of my proverbial rope on this one and dont know how to proceed... i am trying to install libapreq for Apache::Request, and when i try to run make the thing just pukes up a huge long string of errors like: -=-=-=-=-=-=- make[1]: Entering directory `/root/.cpan/build/libapreq-0.33/c' gcc -c -I/usr/local/httpd//include -I/usr/local/httpd//include -fno-strict-aliasing -I/usr/local/include -O2 -march =i386 -mcpu=i686 -DVERSION=\0.10\ -DXS_VERSION=\0.10\ -fPIC -I/usr/lib/perl5/5.6.1/i386-linux/CORE apache_re quest.c In file included from apache_request.c:58: apache_request.h:38: parse error before `table' apache_request.h:38: warning: no semicolon at end of struct or union apache_request.h:48: parse error before `}' apache_request.h:48: warning: data definition has no type or storage class apache_request.h:55: parse error before `table' apache_request.h:55: warning: no semicolon at end of struct or union apache_request.h:58: parse error before `*' apache_request.h:58: warning: data definition has no type or storage class apache_request.h:59: parse error before `}' apache_request.h:89: parse error before `*' apache_request.h:89: warning: data definition has no type or storage class apache_request.h:90: parse error before `*' apache_request.h:91: parse error before `*' apache_request.h:92: parse error before `*' apache_request.h:93: parse error before `*' . . . -=-=-=-=-=-=- it goes on for 200 more lines or so with many different seemingly syntactical errors... i decided for grins to try v0.33 and see what happened, and curiously enough, i get exactly the same errors... well, for the first 50 lines or so, i was just eyeballing the first screen or two... anyone have any idea at all what would cause this? it occurs if i try to do it with the CPAN module or when i do it manually... i even tried it with both the Makefile.PL and using configure... same results... id definitely appreciate any insight any of you might have on how to resolve this... thanks! -Tim http://www.sold.com.au - SOLD.com.au - Find yourself a bargain!
Re: Is mod_perl the right solution for my GUI dev?
From: Fran Fabrizio [EMAIL PROTECTED] You oversimplify. Cookies do work fine. What creates, reads, modifies, validates the cookies? What ties the cookies to useful state information that is stored server-side? There's a lot of coding potentially involved. Yes, perl modules exist. Yes, they'll most likely need customization (in my case, I've customized AuthCookie, and tied it to Apache::Session. It wasn't the end of the world, but it wasn't trivia. A cookie by itself is of rather limited usefulness. You can avoid most of the grunge work here by using one or more of the high-level modules like Embperl, Apache::ASP, Mason, etc. that handle sessions and a lot more for you. One thing that I don't think anyone has mentioned so far that is an inherent advantage to a web interface is that unless you really go out of your way to break it, you automatically end up with a well-defined client-server network interface. Thus as you or your users discover parts of the application that can be completely automated later, someone can easily whip out some scripts with LWP to get/post anything without human intervention where with a traditional GUI it takes a massive effort to ever go beyond pointing and clicking. Making an interface easy to use is often at odds with making it easy to automate, and in the long run anything you can make 'full-auto' is going to save time and money (unless the object of the site is to make the user view a lot of banner ads...). Les Mikesell [EMAIL PROTECTED]
Re: Is mod_perl the right solution for my GUI dev?
Ron Savage wrote: On Tue, 25 Jun 2002 12:22:15 -0400, Fran Fabrizio wrote: Fran [snip] from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated Did you consider using my module CGI::Explorer? I wasn't aware of it's existence. I just now downloaded it and played with the demo. Unfortunately, it looks like it might not have helped in my case. It appears that it is doing a round trip to the server and back on every open/close of a node. That's exactly what I had to avoid. Our tree has 1000 elements (and growing) pulled dynamically out of a database. In a multi-user environment we don't want to be hitting the server that hard just for a navigational menu for every click of every user. We serve up the entire tree when the user logs in, and all of the state maintenance is handled client-side in terms of what's been opened, etc... we never go back to the server unless the user has requested a refresh of the tree. I could be wrong in how your module operates, that's just from a 3 minute session with the demo. It's good that you've made this available though, most people will have more reasonably sized and constructed trees than we do and should find that module useful. :-) -Fran PS - May want to take a look at it on Mozilla. There seemed to be slight table layout issues on my Mozilla 1.0 (yeah, I need to upgrade :-) that caused the graphics to slightly misalign.
Re: Like-named perl modules in separate directories
* Tim Gerla [EMAIL PROTECTED] [2002-06-26 11:33]: I've got a problem with a perl module (.pm) problem on my server. I've got two slightly different versions of a file: Conf.pm, in two separate places on my server. (Let's call them /home/www/docs/web/cgi/ and /home/www/docs/minos/cgi/) Mod_perl apparently keeps caching one or the other, causing interesting problems if I hit a 'web' script, and then a 'minos' script a few minutes later. What's the best way to get around this? Use different namespaces for the two modules. (darren) -- All is fear in love and war.
Re: errors installing libapreq
[cross-posted to apreq-dev] Tim Bolin [EMAIL PROTECTED] writes: ok, im at the end of my proverbial rope on this one and dont know how to proceed... i am trying to install libapreq for Apache::Request, and when i try to run make the thing just pukes up a huge long string of errors like : -=-=-=-=-=-=- make[1]: Entering directory `/root/.cpan/build/libapreq-0.33/c' gcc -c -I/usr/local/httpd//include -I/usr/local/httpd//include -fno-strict-aliasing -I/usr/local/include -O2 -march =i386 -mcpu=i686 -DVERSION=\0.10\ -DXS_VERSION=\0.10\ -fPIC -I/usr/lib/perl5/5.6.1/i386-linux/CORE apache_re quest.c In file included from apache_request.c:58: apache_request.h:38: parse error before `table' ^^ Your include files aren't defining the table struct. gcc can't find your apache header files (maybe they're in /usr/local/apache/include ?). Also, the typical compile lines should have a whole lot more -I flags. In your case, modperl may not be properly installed- otherwise your compile lines would look more like this (wrapped): make[1]: Entering directory `/home/joe/src/apache/cvs/httpd-apreq/c' cc -c -I/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/include -I/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/include/modules/perl -I/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/include/include -I/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/include/regex -I/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/include/os/unix -I/usr/local/apache/include -Dbool=char -DHAS_BOOL -I/usr/local/include -O2-DVERSION=\0.10\ -DXS_VERSION=\0.10\ -fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE apache_request.c You probably need to reinstall modperl (preferably from source) to get libapreq to build correctly on your OS. -- Joe Schaefer
Re: Like-named perl modules in separate directories
At 17:29 26.06.2002, Tim Gerla wrote: I've got a problem with a perl module (.pm) problem on my server. I've got two slightly different versions of a file: Conf.pm, in two separate places on my server. (Let's call them /home/www/docs/web/cgi/ and /home/www/docs/minos/cgi/) Mod_perl apparently keeps caching one or the other, causing interesting problems if I hit a 'web' script, and then a 'minos' script a few minutes later. What's the best way to get around this? RTFM :) http://perl.apache.org/release/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs You should read the whole mod_perl guide. You'll be out of questions afterwards :) -- Per Einar Ellefsen [EMAIL PROTECTED]
mod-perl 2.0 and CGI.pm
Greetings,
Tried to run some benchmarking tests on a cgi generated web page comparing a
light and heavy server.
ab worked fine when testing the script run by the Apache 2.0.39 light server
ab reported failure when testing the same script running on Apache
2.0.40-dev with mod-perl 1.99
Both worked and looked fine when viewed via a browser.
Looking at the source code for each page via the browser I found that the
only difference between
the pages was that the first couple of lines in the mod-perl enabled server
where
?xml version =1.0 encoding=iso-8859-1
!DOCTYPE html
while the first line of the page served by the light server is just
!DOCTYPE html
The cgi script which generates the page has in it
use CGI '-no_xhtml';
In my /conf/startup.pl script for the mod-perl server I tried
use CGI '-no_xhtml';
CGI-compile(':all');
But that didn't stop the xml line from showing up.
So two questions:
Why does ab break when it sees ?xml version ... as the first line (IF that
is the problem)? and
How do I get the mod-perl server to honor use CGI '-no_xhtml'; ?
Thank you,
John Kent
Webmaster
Naval Research Laboratory
Monterey, CA
http://kauai.nrlmry.navy.mil
Re: Apache::DBI with mod_perl 2.0
Ok, still no luck. Every dependancy has more dependancies all of which go
back and back to mod_perl 1 stuff already being in place
My question is, can I download the Apache 1.3 source (don't make it), then
run the mod_perl 1 build to get all the pm files in place, then rebuild my
mod_perl 2 (against my installed Apache 2 source).
Also, we mentioned the whole Bundle::Apache, will there be one of those
for Apache 2 and will it contain all the mod_perl 1 AND mod_perl 2 stuff to
allow running in Compat?
Thanks,
-Zac
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Zac Morris [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 12:26 PM
Subject: Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
http://perl.apache.org/release/docs/index.html
Most of the kludges are documented here:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
There are much more to come, but it'll take time. For now there is more
than enough docs to get yourself started. If something is unclear or
missing please shout aloud.
I'm assuming that the bulk of these things are handled via a CPAN
Apache::bundle install, and because mod_perl2 is still beta we don't
have
that in place yet?
yes, but Apache::Module is an XS module using mod_perl 1.0's API, so it
won't be in the Apache::Bundle for 2.0. This patch may go in soon:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
diff -u -r1.61 compat.pm
--- lib/Apache/compat.pm 4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm 25 Jun 2002 15:17:56 -
@@ -91,7 +91,8 @@
}
sub module {
-require Apache::Module;
+eval { require Apache::Module };
+die Please install Apache::Module from CPAN if $@;
return Apache::Module::loaded($_[1]);
}
Thanks for all this info, learning more and more every day. :)
cool :)
__
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: custom directives, again...
To solve the second problem (Apache::Icon not loading its directives properly), I ended up commenting out all the AddModule statements as well as the ClearModuleList statement in the httpd.conf fiile. I don't really know why this fixed the problem, but I suppose it's related to having statically compiled all the basic modules directly into the httpd binary. The answer came to me when I belatedly remembered having encountered a similar problem a couple months ago on my development server, where I had httpd dynamically loading its binaries, and the problem then turned out to be that I had some modules loading in the wrong order. Hope this helps someone somewhere down the line! - Original Message - From: Per Einar Ellefsen [EMAIL PROTECTED] To: Noam Solomon [EMAIL PROTECTED] Cc: Mod-perl list [EMAIL PROTECTED] Sent: Monday, June 17, 2002 6:37 PM Subject: Re: custom directives, again... At 00:25 18.06.2002, Noam Solomon wrote: Thanks -- that got me over one hurdle! Next one: Syntax error on line 382 of /home/build/httpd/server/./conf/httpd.conf: Invalid command 'AddIconByEncoding', perhaps mis-spelled or defined by a module not included in the server configuration I've replaced the startup.pl call with: #PerlModule Apache::AutoIndex PerlModule Apache::OpenIndex PerlModule Apache::Icon PerlModule Apache::AuthCookie Switching on AutoIndex versus OpenIndex makes no difference. Any idea what could be going on here? I just tried reinstalling Apache::Icon, with no improvement. Sorry, I'm at a loss here. Thanks
Re: errors installing libapreq
On Tue, 25 Jun 2002, Tim Bolin wrote: ok, im at the end of my proverbial rope on this one and dont know how to proceed... i am trying to install libapreq for Apache::Request, and when i try to run make the thing just pukes up a huge long string of errors like: You forgot to mention (though you did in your message to the Mason list) that you're using mod_perl 1.99_something, with which Apache::Request will not compile. -dave /*== www.urth.org we await the New Sun ==*/
notes/pnotes broke between 1.25=1.27
So I got the advisory about the Apache servers having a security hole, so I decided to upgrade some servers. I've been on v1.25 for awhile, so decided to upgrade to 1.27 while I was at it... big mistake. NONE of my notes/pnotes were getting thru, on the new version. It took me 8 or 10 compilations, with 3 different apache versions and 4 different mod_perl versions, to establish that definitiely, on my machine (RedHat Linux 6.2, custom apache, custom perl 5.005_03), the upgrade breaks notes AND pnotes. PLEASE tell me I missed something??? RTFM would be ok but I haven't found it yet. L8r, Rob
[DIGEST] mod_perl digest 2002/06/17
-- mod_perl digest June 17, 2002 - June 23, 2002 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o module rfcs o mod_perler wanted o mailing list highlights o links mod_perl status o mod_perl - stable: 1.27 (released June 1, 2002) [1] - development: 1.27_01-dev [2] o Apache - stable: 1.3.24 (released March 21, 2002) [3] - development: 1.3.25-dev [4] o mod_perl 2.0 - beta: 1.99_04 (released June 21, 2002) [5] - development: (cvs only) [6] o Apache 2.0 - stable: 2.0.35 (released April 5, 2002) [7] o Perl - stable: 5.6.1 (released April 9, 2001) [8] - development: 5.8.0-RC2 [9] module announcements o Apache::AuthCookie 3.02 - provides cookie-based authentication [10] o Apache::DBI 0.89 - provides persistent DBI connections [11] module rfcs o Apache::LightBackhand - transparent proxy [12] mod_perler wanted o Red Hat Web Engineer [13] o Crack OOP Perl whitebox tester [14] mailing list highlights o Banners for mod_perl - contest [15] o Reorganization of Apache:: namespace [16] o Naming convention for Apache 2 modules [17] o mod_perl 1.99_04 announcement [18] o Apache vulnerability and proxy configurations [19] links o The Apache/Perl Integration Project [20] o mod_perl documentation [21] o Apache modules on CPAN [22] o mod_perl homepage [23] o mod_perl news and advocacy [24] o mod_perl list archives - modperl@ [25] [26] - dev@ [27] [28] - docs-dev@ [29] - advocacy@ [30] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_01.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/devel.tar.gz [10] http://mathforum.org/epigone/modperl/trurinquen [11] http://mathforum.org/epigone/modperl/khingpaxgrox [12] http://mathforum.org/epigone/modperl/clomstyrfle [13] http://mathforum.org/epigone/modperl/tronplonlex [14] http://mathforum.org/epigone/modperl/jenzeesnee [15] http://mathforum.org/epigone/modperl/swoubreldbrimp [16] http://mathforum.org/epigone/modperl/skeldkendtrau [17] http://mathforum.org/epigone/modperl/fomsaldloo [18] http://mathforum.org/epigone/modperl/cloxtwoashul [19] http://mathforum.org/epigone/modperl/sauphinggreld [20] http://perl.apache.org/ [21] http://perl.apache.org/#docs [22] http://www.cpan.org/modules/by-module/Apache/ [23] http://www.modperl.com/ [24] http://www.take23.org/ [25] http://mathforum.org/epigone/modperl/ [26] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2 [27] http://marc.theaimsgroup.com/?l=apache-modperl-devr=1w=2 [28] http://www.mail-archive.com/dev%40perl.apache.org/ [29] http://perl.apache.org/mail/docs-dev/ [30] http://www.mail-archive.com/advocacy@perl.apache.org/
Re: Is mod_perl the right solution for my GUI dev?
On Wed, 26 Jun 2002 09:37:58 -0400, Fran Fabrizio wrote:
Fran
Ron Savage wrote:
On Tue, 25 Jun 2002 12:22:15 -0400, Fran Fabrizio wrote:
Fran
[snip]
from first-hand experience, hell my current project has both of
these
things in a web interface, and neither were trivial. I crafted an
expandable-tree menu (think Windows Explorer style menu) from
HTML,
CSS,
JavaScript and HTML::Template. I have graphs dynamically
generated
Did you consider using my module CGI::Explorer?
I wasn't aware of it's existence. I just now downloaded it and
played
with the demo. Unfortunately, it looks like it might not have
helped in
my case. It appears that it is doing a round trip to the server and
back on every open/close of a node. That's exactly what I had to
avoid.
Yes, it does a round trip. Such is life.
Our tree has 1000 elements (and growing) pulled dynamically out of
a
database. In a multi-user environment we don't want to be hitting
the
server that hard just for a navigational menu for every click of
every
user. We serve up the entire tree when the user logs in, and all of
the
state maintenance is handled client-side in terms of what's been
opened,
etc... we never go back to the server unless the user has requested
a
refresh of the tree. I could be wrong in how your module operates,
that's just from a 3 minute session with the demo. It's good that
you've made this available though, most people will have more
reasonably
sized and constructed trees than we do and should find that module
useful. :-)
Thanx.
-Fran
PS - May want to take a look at it on Mozilla. There seemed to be
slight table layout issues on my Mozilla 1.0 (yeah, I need to
upgrade
:-) that caused the graphics to slightly misalign.
That may be due to me using some non-standard (Netscape-specific)
HTML. Eg 'absmiddle' as in
$q - img({src = $image, align = 'absmiddle', width = 17, height
= 17})
And when Mozilla has stabilized, in a year or so, I'll consider
installing it. Reports of its stability today are not going to sway
me :-). Such, too, is life.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 27/06/2002
http://savage.net.au/index.html
Caching in TT2 or Some Mod Perl oddity
I'm in a baffled state, ladies and gentleman.
I'm using TT2 to ultimately display some pages, however I'm having some
rather odd behaviour creeping in.
In my template constructor I have CACHE_SIZE set to 0.
I have a page which - even after a server restart - reverts to an older
version of the page.
Whilst I was still debugging, I accidently had Data::Dumper doing a print
STDOUT and a lovely $VAR1=[] in the corner of my screen. This has long
since been removed from my code, however I keep going through hits of the
same page - as I said, even after a restart - where either I have the
'correct' funky page, or on the next hit reverting to the old over
funked paged.
From my understanding of TT2, it's not the actual page which is cached but
some sort of compiled version of the nested code (?). Thus I'm having
trouble seeing how it might be a TT2 problem, especially with
{CACHE_SIZE=0} whenever Template is instantiated. Is it TT2 or is it
some Mod_Perlus Oddity?
Anyone?
Cheers,
Fiq
'Don't you love her madly?
Don't you need her badly?
Don't you love her ways?
Tell me what you say?
Don't you love her madly?
want to be her daddy?
Don't you love her face?
Don't you love her as she's walking out the door?'
- Jim Morrison, The DoorS.
Died
Folks, I get the strangest object when I tried to print my object to log file: Died. Has anyone seen this before. This is ofcourse my container object that I use in mod_perl to save the request's response. Thanks in advance. -r
Re: Caching in TT2 or Some Mod Perl oddity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jun 26, 2002 at 11:17:49PM +, Rafiq Ismail (ADMIN) wrote: I have a page which - even after a server restart - reverts to an older version of the page. Whilst I was still debugging, I accidently had Data::Dumper doing a print STDOUT and a lovely $VAR1=[] in the corner of my screen. This has long since been removed from my code, however I keep going through hits of the same page - as I said, even after a restart - where either I have the 'correct' funky page, or on the next hit reverting to the old over funked paged. Sounds like browser caching, or a rather borked transparent proxy. Or both. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9GmXLA4aoazQ9p2cRAkFSAJ9tctOR4sNzmtWHhzyVaebftWMcxgCg1Uoh hlAtmfjtL+weqERfSqbCu5Q= =F7ij -END PGP SIGNATURE-
missing .al files with apache/mod_perl
Hi, I asked about this before, but didn't get a response, so here we go again... I'm able to use MPEG::LibMPEG3 in a command line perl script, but if I try to use it under mod_perl, I get an error: [error] Can't locate auto/MPEG/LibMPEG3/dimensions.al in INC ... Furthermore, this file doesn't exist in my filesystem. How is it possible that (1) the module works without this apparently required file at the command line but (2) doesn't work with apache/mod_perl ? -Allen
Re: missing .al files with apache/mod_perl
Allen Day wrote: Furthermore, this file doesn't exist in my filesystem. How is it possible that (1) the module works without this apparently required file at the command line but (2) doesn't work with apache/mod_perl ? How is it possible? Two ways: you could be wrong about the existence of the file, or the situtation that requires the file might only arise when you use it with mod_perl. I'd suggest you start debugging it by looking at the things that are different when running it from mod_perl: the user, environment variables, working directory, ways that you call it, etc. One of those things is probably responsible. - Perrin
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, still no luck. Every dependancy has more dependancies all of which go back and back to mod_perl 1 stuff already being in place My question is, can I download the Apache 1.3 source (don't make it), then run the mod_perl 1 build to get all the pm files in place, then rebuild my mod_perl 2 (against my installed Apache 2 source). Sorry Zac, my diagnosis and patch were wrong. mod_perl 2.0's compat layer doesn't require mod_perl 1.0 to be installed, sorry for confusing people. Apache::Module *is* in 2.0. But for some reason it didn't work for you. So let's try to investigate why. It seems to me that you have Apache::Module for 1.0 installed and it gets loaded instead of 2.0's version. Can you list all Apache/Module found on your machine (pm, so, etc)? locate Apache/Module I'm certain that if you install mod_perl 2.0 into Apache2/ dirs (even though you don't have mod_perl 1.0 installed) this problem will go away. But I'd still like to figure out what kind of collission you have now. Also, we mentioned the whole Bundle::Apache, will there be one of those for Apache 2 and will it contain all the mod_perl 1 AND mod_perl 2 stuff to allow running in Compat? no, it'll contain only stuff needed for 2.0, which may include modules that work for both mod_perls, but definitely not mod_perl 1.0. Again I apologize for my mistake. __ 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: mod-perl 2.0 and CGI.pm
Kent, Mr. John wrote: Greetings, Tried to run some benchmarking tests on a cgi generated web page comparing a light and heavy server. ab worked fine when testing the script run by the Apache 2.0.39 light server ab reported failure when testing the same script running on Apache 2.0.40-dev with mod-perl 1.99 any luck with ab from 2.0.40? I've just done some testing with CGI.pm (it was printing the whole set of xml headers) and it seems to be fine (with ab from 1.3 and 2.0). Care to send a *short* script that represents the problem? __ 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: ANNOUNCE: mod_perl-1.99_04
So that this question won't be repeated again and again: If you build with perl 5.8.0, you need perl-5.8.0-RC2 in order to build mod_perl-1.99_04. If you use 5.6.(0|1), please disregard this note. __ 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
