Re: problem with mod_perl 2.0 + apache 2.0 and proxyreq
John Chiu wrote: Thanks in advance. I've tried all the archives and google'd but I have not found anything that would help. I'm running RH 8.0, httpd-2.0.40-11.5 and mod_perl-1.99_05-3 from the RedHat distribution. I'm trying to create a small proxy module that will check a non-proxy request and depending on stuff dynamically transform it into a proxy request using mod_proxy. 1.99_05 is a way too old. Lots of bugs were fixed since that release. Upgrade to at least 1.99_09 or better the current cvs. 1.99_10 will be released as soon as perl-5.8.1 is released. I'm following the example in Chapter 7 (page 370) of the Writing Apache Modules with Perl and C. I know that the book is based on the older apache 1.3 server and associated mod_perl. However, I have not found anything in my readings to indicate that this would not work any more. my $r =3D shift; [... code snipped ...] BTW, you mailer has mangled the source code, s/=/=3D/ Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request. The apache error log indicates (with some debugging) that it is looping on the GET of goodbye.html. Additional debuging indicates that $r-proxyreq is always 0, so it's looping. My questions are: 1.Did sometime change in apache 2 or mod_perl 2 so that you cannot set proxyreq anymore: ie. $r-proxyreq(1). 2.How do you set proxyreq if $r-proxyreq(1) is not the correct method? 3.Is the logic wrong in this proxy example? How can we possible know what the problem is if you don't show the relevant configuration section? Most likely you have a broken configuration and should advise first the mod_proxy documentation. http://httpd.apache.org/docs-2.0/mod/mod_proxy.html To make sure that the problem is not in mod_perl, I've added a new modules/proxy test to the mp2 test suite, based on that example from the eagle book. Try it and if you succeed to break it, then we will fix it. You will need to retrieve the cvs version in order to get it. http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution (note: I have just committed the test, so if you use the snapshot, which is updated every 6 hours, it may not be there, so use the normal cvs checkout) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
mod_perl 2.0 and cookies
So Ive decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didnt know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I dont think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. Thank you, Jamie
Re: mod_perl 2.0 and cookies
So I've decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didn't know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I don't think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. From what I've figured out through experiementing, tho I'd find out a lot more by reading source and I'd be a bit more accurate in this... But I think mod_perl 2 is just simply lacking all together. I think the docs are lacking info because the program is lacking hte feature! Course, this only means I havern't figured out how to use the features, if they are there. But, to me, mod_perl x+1 should be backwards compatible with mod_perl x, if it isn't, then it's broken. (in my opinion..) Dennis
Re: mod_perl 2.0 and cookies
On Fri, 11 Jul 2003, Jamie Krasnoo wrote: So I've decided to dive headlong into 2.0. So far I like it but find the documentation lacking and there seems to be a lot missing. I tried Apache::Cookie with it, no dice. It gave an error to the effect that it didn't know what bootstrap was (I think that was it). Apache::Cookie made inserting cookies in mod_perl 1.0 so easy which in turn made life easier for programming. However I have scoured the documentation on how to insert a cookie into the header and the only thing I could come up with is that you use a filter to do it. Somehow I don't think that this is right and I am completely off. Could someone enlighten me as to how cookies work in MP2? If I can get past this I can figure out the rest on my own and maybe write a little documentation if I can understand it enough to do so. It wasn't clear to me - are you using the development version of httpd-apreq-2? The CPAN version of libapreq are for mod_perl 1 - you'll need httpd-apreq-2 (available via cvs) for Apache 2. If you are using Apache::Cookie of httpd-apreq-2, at this point, probably the simplest way to see examples of the basic usage is to go through the tests, under glue/perl/t/. Documentation patches would be welcome - it would be easiest to subscribe to the [EMAIL PROTECTED] mailing list and submit them there. -- best regards, randy kobes
RE: mod_perl 2.0 and cookies
On Fri, 11 Jul 2003, Ross Matt-QMR000 wrote: I would really like to be removed from this list but the un-scribe does not work for me. the problem is the mail address that I used way back when has been aliases to different address. Try sending a message to [EMAIL PROTECTED] for some suggestions. -- best regards, randy kobes
Re: MOD_PERL 2.0?
On Thu, 29 May 2003, FARRINGTON, RYAN wrote: -- I don;t know if the first message was sent but here it is again -- just as a test I used the ALL in ONE package to get this installed and it works like a champ except for Apache::compat errors with something about line 68. =( I don't have the error infront of me but it is something like method not defined. It would help to know - what operating system you're using, - what minimal script and configuration set off the error, - what the error was. -- best regards, randy kobes
MOD_PERL 2.0?
Title: MOD_PERL 2.0? just as a test I used the ALL in ONE package to get this installed and it works like a champ except for Apache::compat errors with something about line 68. =( I don't have the error infront of me but it is something like method not defined.
perl.com: Testing mod_perl 2.0
for those who haven't already seen it, perl.com ran the second of my series of articles on mod_perl 2.0 late last week. the title is actually a bit decieving. it's about using the Apache-Test testing framework, but although Apache-Test is shown in a mod_perl 2.0 context, Apache-Test can be used with mod_perl 1.0 as well - many of the illustrations are cross platform. the code from the article can be downloaded from http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz or, for the mod_perl 1.0 version, http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-1.0.tar.gz if you're interested in trying it out. enjoy --Geoff In our continuing mod_perl 2.0 series, Geoff Young looks at the new testing scheme, Apache-Test, and how it fits in with your mod_perl programs. http://www.perl.com/pub/a/2003/05/22/testing.html
register_cleanup on mod_perl 2.0
Hi!
I've a script that looks like this:
if ($runnung_on_mod_perl) {
Apache-request-register_cleanup(\init_globals);
}
Under mod_perl 1.0 works fine with Apache::Registry.
Can someone give me an Example how to make a register_cleanup with mod_perl
2?
Thanks a lot
Denis
Re: register_cleanup on mod_perl 2.0
Denis Banovic wrote:
Hi!
I've a script that looks like this:
if ($runnung_on_mod_perl) {
Apache-request-register_cleanup(\init_globals);
}
Under mod_perl 1.0 works fine with Apache::Registry.
Can someone give me an Example how to make a register_cleanup with mod_perl
2?
A copy-n-paste from Apache/compat.pm:
sub register_cleanup {
shift-pool-cleanup_register(@_);
}
if you use Apache::compat, your mp1 code will work under mp2 unmodified.
__
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: register_cleanup on mod_perl 2.0
Stas Bekman wrote:
Denis Banovic wrote:
Hi!
I've a script that looks like this:
if ($runnung_on_mod_perl) {
Apache-request-register_cleanup(\init_globals);
}
Under mod_perl 1.0 works fine with Apache::Registry.
Can someone give me an Example how to make a register_cleanup with
mod_perl
2?
A copy-n-paste from Apache/compat.pm:
sub register_cleanup {
shift-pool-cleanup_register(@_);
}
if you use Apache::compat, your mp1 code will work under mp2 unmodified.
And it is documented here:
http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_register_cleanup_
http://perl.apache.org/docs/2.0/user/compat/compat.html#C__s_E_gt_register_cleanup_
In the future please refer to the docs first, before asking on the list.
__
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 question about $r-connection-auth_type
I've just about got the Apache::AuthCookieDBI to work with Apache 2.0.44 mod_perl 1.99_09-dev, but I ran into a problem with the $r-connection object not having auth_type or user defined. The $r-auth_type work just fine. Are these the same reference? What should I look for, or use? [snip] Geoff is working on the proper fix for your original problem. When that's done please check that test again. (see the dev list for developments) the fix has been committed, so you should be good to go based on the discussions we had over on dev@. remember, we added a new method, so you'll have to build mod_perl from CVS and make realclean before building if you want to pick up the new method. lemme know how it goes. --Geoff
Re: mod_perl 2.0 question about $r-connection-auth_type
Stas Bekman wrote: Brian Millett wrote: Hi, I've just about got the Apache::AuthCookieDBI to work with Apache 2.0.44 mod_perl 1.99_09-dev, but I ran into a problem with the $r-connection object not having auth_type or user defined. The $r-auth_type work just fine. Are these the same reference? What should I look for, or use? They don't live in the connection record in 2.0, only in the request record. I've added Apache::compat methods for backwards compatibility. Notice that you need to set up: PerlOptions +GlobalRequest for that location. Either use the latest modperl-2.0 cvs or apply this patch to get the functionality: http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=104509336821414w=2 Thanks Stas. However the latest cvs co (as 10 minutes ago) returns this error testing: compat/conn_authen.NOK 1# Failed test 1 in compat/conn_authen.t at line 11 compat/conn_authen.FAILED test 1 Failed 1/1 tests, 0.00% okay From the error_log: [Thu Feb 13 09:10:04 2003] [error] [client 127.0.0.1] Can't locate object method auth_type via package Apache::Connection at /home/bpm/compile_area/cvs_apache/modperl-2.0/t/response/TestCompat/conn_authen.pm line 25. This is against http-2.0.44 on a solaris 9 box with gcc version 3.1. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn
mod_perl 2.0 question about $r-connection-auth_type
Hi, I've just about got the Apache::AuthCookieDBI to work with Apache 2.0.44 mod_perl 1.99_09-dev, but I ran into a problem with the $r-connection object not having auth_type or user defined. The $r-auth_type work just fine. Are these the same reference? What should I look for, or use? Thanks. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn
Re: mod_perl 2.0 question about $r-connection-auth_type
Brian Millett wrote: Hi, I've just about got the Apache::AuthCookieDBI to work with Apache 2.0.44 mod_perl 1.99_09-dev, but I ran into a problem with the $r-connection object not having auth_type or user defined. The $r-auth_type work just fine. Are these the same reference? What should I look for, or use? They don't live in the connection record in 2.0, only in the request record. I've added Apache::compat methods for backwards compatibility. Notice that you need to set up: PerlOptions +GlobalRequest for that location. Either use the latest modperl-2.0 cvs or apply this patch to get the functionality: http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=104509336821414w=2 Also the online docs were updated (pending automatic update) __ 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
AW: [mod_perl-2.0] server doesn't start, unable to Apache2?
Hi all! Thanks for your thoughts, Randy. Are there any helpful messages in the error log indicating what's failing? No, none. Perhaps the first thing to check - does LoadFile C:/Perl/bin/perl56.dll LoadModule perl_module modules/mod_perl.so alone, without any further mod_perl directives, prevent the server from starting? That works ok, for Perl 5.6.1 and 5.8.0. Surely I can't execute any perl then. The browser starts to load a page, but does not finish. After several minutes(!) it says 404. If so, then it might be that you're running into the fact that mod_perl 2.0 on Win32 has problems with perl-5.6.1 (ActivePerl 6xx), and that the solution would be to migrate to perl-5.8.0 (ActivePerl 8xx). As long as I don't have a DBD-Mysql afterwards, that's not possible other than for testing. But it's the same for 5.8.0 - crashing, too. However, if the server starts OK above, but things like PerlModule Apache2 cause it to crash, then it might be a misconfiguration, Ok, but where to configure? or faulty installation, or something similar. If this is the case, the error log should give a clue about what's failing. Nope, it doesn't, stays absolutely clear. The only thing happens is a small dialogue box popping up saying The requested operation has failed. Same happens if I comment PerlModule Apache2 and uncomment PerlRequire, if if the file to be required consists only of comments! Thanks again for your help, Robert
Re: AW: [mod_perl-2.0] server doesn't start, unable to Apache2?
On Mon, 27 Jan 2003, Robert Kehl wrote: Hi all! Thanks for your thoughts, Randy. Are there any helpful messages in the error log indicating what's failing? No, none. Perhaps the first thing to check - does LoadFile C:/Perl/bin/perl56.dll LoadModule perl_module modules/mod_perl.so alone, without any further mod_perl directives, prevent the server from starting? That works ok, for Perl 5.6.1 and 5.8.0. Surely I can't execute any perl then. This was just to test that the mod_perl.so module was OK, which apparently it is. The browser starts to load a page, but does not finish. After several minutes(!) it says 404. Is this even for a static page? You mentioned earlier that without mod_perl, CGI scripts execute OK, but are slow ... This might be a more general problem that should be looked at first If so, then it might be that you're running into the fact that mod_perl 2.0 on Win32 has problems with perl-5.6.1 (ActivePerl 6xx), and that the solution would be to migrate to perl-5.8.0 (ActivePerl 8xx). As long as I don't have a DBD-Mysql afterwards, that's not possible other than for testing. But it's the same for 5.8.0 - crashing, too. There's a DBD-mysql ppm package for ActivePerl 8xx available in our http://theoryx5.uwinnipeg.ca/ppms/ repository. However, if the server starts OK above, but things like PerlModule Apache2 cause it to crash, then it might be a misconfiguration, Ok, but where to configure? or faulty installation, or something similar. If this is the case, the error log should give a clue about what's failing. Nope, it doesn't, stays absolutely clear. The only thing happens is a small dialogue box popping up saying The requested operation has failed. Same happens if I comment PerlModule Apache2 and uncomment PerlRequire, if if the file to be required consists only of comments! Does Apache2.pm exist on your system (under, eg, C:\Perl\site\lib)? And does the file you use for PerlRequire have a '1;' as the last line (ie, return a true value)? If both of these are OK, then the fact that even these fail indicate something seriously wrong - these are really basic things. If the above doesn't help, I'd suggest, first of all, making sure Apache 2 works OK without mod_perl, including perl cgi scripts (simple pages and scripts should be served very fast). When you're satisfied with that, using Perl 5.8 if possible, remove existing mod_perl packages (1.0 and 2.0), and then reinstall mod_perl 2.0, making sure that mod_perl.so gets installed into your Apache2 modules/ directory. Then try loading mod_perl, and assuming that works, start adding simple things like you were doing - loading Apache2, and requiring a simple startup file. -- best regards, randy
[mod_perl-2.0] server doesn't start, unable to Apache2?
Hi all, if you would be willing to spend a minute on helping me out of this: I'm trying to get mod_perl-2 running on Win32. Without success, of course. :( My box is a Win2k SP3 with 1GB RAM, ActivePerl 5.6.1 build 633, mod_perl-2 1.99_09-dev on Apache 2.0.43. Everything is freshly loaded and installed. Btw, mod_perl 1.27_01-dev is running smoothly on Apache 1.3.27. This is my startup.pl, loaded in httpd.conf by an Include directive: LoadFile D:/Perl/bin/perl56.dll LoadModule perl_module modules/mod_perl.so IfModule mod_alias.c Alias /somewhere/ d:/somewhere/bin/cgi-bin/ /IfModule Location /somewhere Options ExecCGI Order deny,allow Deny from all Allow from 127.0.0.1 ### normal CGI operation if no mod_perl support SetHandler cgi-script ScriptInterpreterSource registry IfModule mod_perl.c SetHandler perl-script # SetHandler modperl PerlOptions +ParseHeaders PerlHandler ModPerl::Registry # PerlResponseHandler ModPerl::Registry # PerlHandler Apache::Registry # PerlResponseHandler Apache::Registry # PerlModule Apache2 # PerlModule Apache::compat # PerlRequire some-script.pl /IfModule /Location MaxRequestsPerChild 400 You see I commented several lines out. Be sure I tried every combination of commenting/uncommenting these. The hardest thing is, not even this works ok: PerlModule Apache2 The server simply doesn't start, so it can't be a fault in some-script.pl, which indeed is nothing more than a series of commented lines atm. Surely *no* perl script gets executed using the above configuration. If I do not load mod_perl, CGI executes fine. But slow ;) So, IMHO, the problem is, that mod_perl-2 doesn't load PerlModule Apache2. Doesn't load anything. Any ideas despite reinstalling everything? ;) Thank you for your attention and for your help, Robert Kehl Nürnberg, Germany www.robertkehl.de
Re: [mod_perl-2.0] server doesn't start, unable to Apache2?
On Sun, 26 Jan 2003, Robert Kehl wrote: Hi all, if you would be willing to spend a minute on helping me out of this: I'm trying to get mod_perl-2 running on Win32. Without success, of course. :( My box is a Win2k SP3 with 1GB RAM, ActivePerl 5.6.1 build 633, mod_perl-2 1.99_09-dev on Apache 2.0.43. Everything is freshly loaded and installed. Btw, mod_perl 1.27_01-dev is running smoothly on Apache 1.3.27. [ ... ] The hardest thing is, not even this works ok: PerlModule Apache2 The server simply doesn't start, so it can't be a fault in some-script.pl, which indeed is nothing more than a series of commented lines atm. Surely *no* perl script gets executed using the above configuration. If I do not load mod_perl, CGI executes fine. But slow ;) So, IMHO, the problem is, that mod_perl-2 doesn't load PerlModule Apache2. Doesn't load anything. Any ideas despite reinstalling everything? ;) Thank you for your attention and for your help, Are there any helpful messages in the error log indicating what's failing? Perhaps the first thing to check - does LoadFile C:/Perl/bin/perl56.dll LoadModule perl_module modules/mod_perl.so alone, without any further mod_perl directives, prevent the server from starting? If so, then it might be that you're running into the fact that mod_perl 2.0 on Win32 has problems with perl-5.6.1 (ActivePerl 6xx), and that the solution would be to migrate to perl-5.8.0 (ActivePerl 8xx). However, if the server starts OK above, but things like PerlModule Apache2 cause it to crash, then it might be a misconfiguration, or faulty installation, or something similar. If this is the case, the error log should give a clue about what's failing. -- best regards, randy kobes
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
On Thu, Jan 16, 2003 at 10:27:38AM +1100, Stas Bekman wrote:
Cool. Now can you please send the shortest possible example that you still
get the SEGFAULT with, so I can reproduce it and fix? Thanks.
I finally got a working apache2+mod_perl working in my $HOME dir (I
could not find the core files of the RedHat httpd, problems with uid
permission i guess)
So here are the backtraces.
I included two backtraces :
- the first one is for the crash with $r-send_http_header()
- the second one is for the crash with $r-print() when I remove the
send_http_header() statement
The config in httpd.conf :
# mod_perl
LoadModule perl_module modules/mod_perl.so
PerlModule Apache2
PerlTransHandler Apache::SegFault
# proxy
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
ProxyRequests On
Proxy *
Order deny,allow
Deny from all
Allow from localhost
/Proxy
Then I issue a simple request with :
echo -ne GET http://perl.apache.org HTTP/1.0\n\n | nc localhost 8081
-8-- Start Bug Report 8--
1. Problem Description:
BEGIN
package Apache::SegFault;
use strict;
use Apache::compat;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::RequestUtil;
use Apache::Const;
use Apache::ServerUtil;
use Apache::Response;
use Apache::URI;
use APR::Table;
sub handler {
my $r = shift;
return Apache::DECLINED unless( $r-proxyreq );
print STDERR Good, this is a proxyreq ...\n;
return Apache::DECLINED unless( $r-method eq GET );
print STDERR Good, this is a GET method ...\n;
my $content = htmlbodyplop/body/html;
my %headers_out;
$headers_out{ 'Content-length' } = length( $content );
$headers_out{ 'Content-type' } = 'text/html';
foreach (keys %headers_out) {
$r-headers_out-{$_} = $headers_out{$_};
}
$r-content_type( $headers_out{ 'Content-type' } );
print STDERR -- send/print --\n;
# -- SEGFAULT here
$r-send_http_header();
# -- or here, when removing the send_http_header() line above
$r-print( $content );
print STDERR -- end --\n;
return Apache::OK;
}
1;
END
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS= /home/jauge/httpd/bin/apxs
MP_DEBUG = 1
MP_GENERATE_XS = 1
MP_LIBNAME = mod_perl
MP_MAINTAINER = 1
MP_TRACE = 1
MP_USE_DSO = 1
MP_USE_STATIC = 1
*** /home/jauge/httpd/bin/httpd -V
Server version: Apache/2.0.43
Server built: Jan 16 2003 15:38:17
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR=server/mpm/prefork
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/home/jauge/httpd
-D SUEXEC_BIN=/home/jauge/httpd/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_LOCKFILE=logs/accept.lock
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi
uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt
2002 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost
-Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr
-Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib
-Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm
-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl
-Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote: On Thu, Jan 16, 2003 at 10:27:38AM +1100, Stas Bekman wrote: Cool. Now can you please send the shortest possible example that you still get the SEGFAULT with, so I can reproduce it and fix? Thanks. I finally got a working apache2+mod_perl working in my $HOME dir (I could not find the core files of the RedHat httpd, problems with uid permission i guess) So here are the backtraces. I included two backtraces : - the first one is for the crash with $r-send_http_header() - the second one is for the crash with $r-print() when I remove the send_http_header() statement The problem is that you were calling these functions before the response phase (PerlTransHandler in your case), hence triggered the segfaults. I've fixed those in cvs. Now if you call any of these functions too early mod_perl will croak. Please verify with the latest cvs. To solve your particular case, you need to use: $r-set_handlers(PerlResponseHandler = \response); inside the PerlTransHandler handler, and move all the code that generates the response there. __ 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 print/send_http_header method SEGFAULT
On Wed, Jan 15, 2003 at 09:09:37AM +1100, Stas Bekman wrote: I've applied a fix that hopefully cures this thing in cvs. Please try again with the latest cvs version. http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution I installed the CVS version (1.9909) and I still get a SEGFAULT when using $r-send_http_header() or $r-print() ... - I fetched the mod_perl CVS sources then launched : $ perl Makefile.PL MP_APXS=/usr/sbin/apxs $ make $ make install - modified the /etc/httpd/conf.d/perl.conf file - restarted httpd I also tested with the Apache::ProxyPassThru module (from http://perl.apache.org/dist/contrib/ProxyPassThru.pm) I added a use Apache::compat statement, removed the $r-handler()/$r-push_handlers() part and I also get a SEGFAULT when it reach the http_send_header() statement ... --
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
I grep'ed into the mod_perl sources and found in
examples/lib/Apache/HelloWorld.pm that send_http_header does not exists
in mod_perl 2.0 and print is not yet implemented. Is this right ? so
this could easily explain my problems :)
in examples/lib/Apache/HelloWorld.pm :
[...]
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
[...]
--
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
On Wed, Jan 15, 2003 at 09:09:37AM +1100, Stas Bekman wrote:
I've applied a fix that hopefully cures this thing in cvs. Please try
again with the latest cvs version.
http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
Since you've never sent the backtrace of SEGFAULT, as explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
there can be more than one problem. I've fixed one, but there can be more
lurking behind the first one. So if you can send the backtrace, that will
help a lot.
I installed the CVS version (1.9909) and I still get a SEGFAULT when
using $r-send_http_header() or $r-print() ...
- I fetched the mod_perl CVS sources then launched :
$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
$ make
$ make install
- modified the /etc/httpd/conf.d/perl.conf file
- restarted httpd
Cool. Now can you please send the shortest possible example that you still
get the SEGFAULT with, so I can reproduce it and fix? Thanks.
I also tested with the Apache::ProxyPassThru module (from
http://perl.apache.org/dist/contrib/ProxyPassThru.pm)
I added a use Apache::compat statement, removed the
$r-handler()/$r-push_handlers() part and I also get a SEGFAULT when it
reach the http_send_header() statement ...
send_http_header is indeed doesn't exist in 2.0, but implemented in
Apache::compat and should work just fine, as it's exercised in many tests:
grep -Ir send_http_header t
t/compat/request_body.t:# $r-send_http_header('text/plain');
t/compat/request_body.t:q{$r-send_http_header('text/plain')}
t/response/TestCompat/request_body.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_file.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_table.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_util.pm:$r-send_http_header('text/plain');
t/response/TestCompat/request.pm:$r-send_http_header('text/plain');
__
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 print/send_http_header method SEGFAULT
Jérôme Augé wrote:
I grep'ed into the mod_perl sources and found in
examples/lib/Apache/HelloWorld.pm that send_http_header does not exists
in mod_perl 2.0 and print is not yet implemented. Is this right ? so
this could easily explain my problems :)
It's an old example, I've removed it.
in examples/lib/Apache/HelloWorld.pm :
[...]
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
[...]
--
__
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 print/send_http_header method SEGFAULT
On Tue, Jan 14, 2003 at 12:32:29PM +1100, Stas Bekman wrote:
Location /plop/
SetHandler perl-script
PerlHeaderParserHandler Apache::Plop
/Location
Well, this is not really what I want to do ...
I would like to catch all the proxy request and apply modifications to
the requested document before forwarding the answer back to the client.
That's why I used the PerlTransHandler which is global and not tied
to a particular directory.
Now to your code:
1. You can't push_handlers when you are inside a response handler.
Use PerlHeaderParserHandler instead
2. $r-headers_in-do() expects a return value and will abort on 0; see
the attached code
also it should be:
$request-header( $_[0] = $_[1] );
instead of:
$request-header( {$_[0]} = $_[1] );
have you looked at error_log? You'd have seen that error reported.
3. This is not good:
my $request = HTTP::Request-new( $r-method, $r-uri);
since you don't the whole url. Use this instead:
my $request = HTTP::Request-new( $r-method, $r-construct_url);
this requires 'use Apache::URI'
4. Finally I've used a special header: (which can be anything)
$request-header( GetReal = 1 );
to know that now I'm inside the real request.
Thanks for your remarks.
I installed modperl-1.99_08 and I keep getting SEGFAULT with my original
code ... I think I'll try to get it working first on mod_perl 1.x then
get back to modperl 2
--
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
Hi,
I'm beginning with mod_perl (mod_perl-1.99_05 + Apache 2.0.40 from
RedHat 8.0) and I want to write a module for rewriting the documents
that passes through the Apache proxy. So, I looked at the
Apache::AdBlocker
(http://perl.apache.org/docs/tutorials/tips/mod_perl_tricks/mod_perl_tricks.html#A_Banner_Ad_Blocker)
module and I'm facing some problems for writing the content of the
documents back to the client.
My main problem is that I get a SEGFAULT when calling the $r-print()
or $r-send_http_header() method.
I get the request, copy the headers from headers_in, make my own
request with LWP, copy the headers to headers_out, then it SEGFAULT
when writing the document ... Are this methods deprecated/not fully
implemented ? what is the correct way to write data to the client ?
The other problem is that if I use the $r-push_handlers(PerlHandler =
\proxy_handler) mechanism, my proxy_handler() function is never
called, so I do the work directly into the handler sub, is this ok ?
I attached my test module below (I register it with a PerlTransHandler
Apache::Plop statement in httpd.conf)
After making your example work, I don't see any segfaults. Please try
again with modperl-1.99_08 which was released a few days ago.
I've attached Plop.pm that apparently works. Hope that this is what you
wanted to accomplish. I've used the following config:
Location /plop/
SetHandler perl-script
PerlHeaderParserHandler Apache::Plop
/Location
Now to your code:
1. You can't push_handlers when you are inside a response handler.
Use PerlHeaderParserHandler instead
2. $r-headers_in-do() expects a return value and will abort on 0; see
the attached code
also it should be:
$request-header( $_[0] = $_[1] );
instead of:
$request-header( {$_[0]} = $_[1] );
have you looked at error_log? You'd have seen that error reported.
3. This is not good:
my $request = HTTP::Request-new( $r-method, $r-uri);
since you don't the whole url. Use this instead:
my $request = HTTP::Request-new( $r-method, $r-construct_url);
this requires 'use Apache::URI'
4. Finally I've used a special header: (which can be anything)
$request-header( GetReal = 1 );
to know that now I'm inside the real request.
Hope that this helps.
Also you might want to use a sub-request rather than a heavy weighted LWP
to accomplish what you do.
__
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
package Apache::Plop;
use strict;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::RequestUtil;
use Apache::Const;
use Apache::ServerUtil;
use Apache::Response;
use Apache::URI;
use APR::Table;
use LWP::UserAgent;
my $ua = LWP::UserAgent-new();
sub handler {
my $r = shift;
if( $r-proxyreq ) {
return Apache::DECLINED;
}
print STDERR Good, this is a proxyreq ...\n;
$r-handler(perl-script); #ok, let's do it
$r-push_handlers(PerlResponseHandler = \proxy_handler);
return Apache::OK;
}
sub proxy_handler {
my $r = shift;
if( $r-method ne GET ) {
return Apache::DECLINED;
}
print STDERR Good, this is a GET method ...\n;
if ( ($r-headers_in-get('GetReal')||0) == 1) {
$r-content_type('text/plain');
print hey;
return Apache::OK;
}
# prepare the real request
my $request = HTTP::Request-new( $r-method, $r-construct_url);
# copy headers from client request
my %headers_in;
print STDERR -- client headers --\n;
$r-headers_in()-do(
sub {
warn $_[0]: $_[1]\n;
$headers_in{ $_[0] } = $_[1];
$request-header( $_[0] = $_[1] );
return 1;
}
);
print STDERR -- end --\n;
# make the real request myself
$ua-agent( $headers_in{ 'User-Agent' } );
$request-header( GetReal = 1 );
warn $request-as_string;
my $response = $ua-request( $request );
if ( ! $response-is_success() ) {
print STDERR == ERROR ==\n;
return Apache::DECLINED;
}
print STDERR -- server headers --\n;
my %headers_out;
$response-headers()-scan(
sub {
print STDERR $_[0]: $_[1]\n;
$headers_out{$_[0]} = $_[1];
}
);
print STDERR -- end --\n;
# simply override the content
my $content = $response-content;
$content = htmlbodyplop/body/html;
# adjust the headers for the new content
$headers_out{ 'Content-length' } = length( $content );
$headers_out{ 'Content-type' } = 'text/html';
# copy the modified response headers back to Apache
foreach (keys %headers_out) {
$r-headers_out-{$_} = $headers_out{$_};
}
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Stas Bekman wrote: Jérôme Augé wrote: [...] After making your example work, I don't see any segfaults. Please try again with modperl-1.99_08 which was released a few days ago. [...] 1. You can't push_handlers when you are inside a response handler. Use PerlHeaderParserHandler instead I've played some more with your original code and did find the segfault you were talking about. Though it happens when you use push_handlers in the same phase to which you push to. Hence I didn't see it in the code that I've fixed. So most likely your _05 version will work just fine with the version that I've posted in my original reply. Meanwhile I'm looking at how it's the best to prevent from the segfault to happen and push_handlers() be used in a wrong place. __ 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: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn'twork?
Dale Lancaster wrote: Thanks for the information. I did try removing Apache:DBI, but it still fails. OK Building everything from source will be time consuming. If I do that, I will probably just drop back to Apache 1.3 since I know it works. It's not time consuming at all, just follow the copy-n-paste recipe from the install page for 2.0. It'll help a lot if you try that first and verify that the bug hasn't been fixed already. __ 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: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn't work?
Thanks for the information. I did try removing Apache:DBI, but it still fails. Building everything from source will be time consuming. If I do that, I will probably just drop back to Apache 1.3 since I know it works. If I can, I will attempt to produce a simple CGI script that fails. The ones that I have in place are simply too complex to send off to you. I will try to narrow it down since I want to stick with the latest stuff. I suspect would of the internal handlers is just not staying hooked up. The debugging show it getting to the eval statement for the script, but it appears as though either the script is empty or it never really eval'd, even though a positive return came back. I'll try to get you something to work with... thanks! dale -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 8:21 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn't work? Dale Lancaster wrote: I have searched the archives and various websites to find my problem and its associated resolution to no avail. I upgraded my working Apache 1.3 and mod_perl 1.x website using the PerlRun option of modperl to the RedHat 8.0 standard release with Apache/mod_perl 2.0 combo -- bad move it appears. ModPerl::Registry and friends are in beta now. I've ported the 1.0's version and made it a bit more modular via ModPerl::RegistryCooker. It's quite possible that I broke some of the functionalities while porting as you saw in the recent bug fix. The problem is that I couldn't verify whether the porting was 1:1 because there was no exhaustive test suite. For 2.0 we are hoping to have one. First, disable Apache::DBI. Does the problem persist? Second, please download the latest cvs versions of apache and mod_perl and try again. Does the problem persist? If it does, please send a short script that reproduces the problem, and hopefully a self-contained one, so it's not relying on mysql. In short, think of it this way: To solve the problem, I need to reproduce it first. So help me to accomplish that first. __ 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
RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn't work?
I have
searched the archives and various websites to find my problem and its associated
resolution to no avail.
I
upgraded my working Apache 1.3 and mod_perl 1.x website using the PerlRun option
of modperl to the RedHat 8.0 standard release with Apache/mod_perl 2.0 combo --
bad move it appears.
When I
start mod_perl on my website, the first couple of CGI loads on a given script
work and then I begin to receive blank page responses. Meaning,I
refresh the page and the response is just blank. No errors, no text (other
than a standard header). Looking in the log file all I see
is:
[24/Dec/2002:12:56:10 -0500] "GET /cgi-bin/filter.cgi?Mode=ListApplicants
HTTP/1.1" 200 0 "http://mysite.com/cgi-bin/jobs.cgi?Mode=DisplayResponses" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
Q312461)"
and the error log
indicates no errors at all. Note the above that I have a 200 status with 0
bytes, when in reality when it does work, it should show several thousand bytes
of transfer. After a few more refreshes, I get output that I expect.
This happens with all of my scripts, not just the same one. If I restart
the server, it always works the first time. Invariably the first and
subsequent refreshes tend to fail (produce blank pages).
I have enabled any
and all types of debugging. I found in RegisteryCooker where I could
enable some debugging and it shows it going through, loading and compiling the
script, running it and then flushing the namespace, but no HTML output
occurs.
I am using the
prefork() MPM and fiddled with various settings to no avail. I have
ensured that caching is disabled, I have played with mod_expire settings, moved
the mod_perl module to be loaded first and all kinds of stuff just to try and
get the behavior to change, all to no avail as well. I also used some
suggestions on how to use the mod_perl::Registry with settings to force it to
restart threads everytime and it doesn't work either. My scripts all use
DBI with mysql. I have noticed that the mysql server is not being hit when
the script produces a blank response. So that tells me that either the
"eval{}" call in RegistryCooker is really not working somehowor the script
is simply not running, but producing no errors anywhere. I don't know why
the eval{} call to run my script would work the first time and fail the second
time, strange.
My perlrun
configuration is:
PerlModule
Apache2PerlModule Apache::DBIPerlRequire
/etc/httpd/conf.d/startup.pl
Directory /home/usa/cgi-bin
SetHandler perl-script PerlHandler
ModPerl::PerlRun PerlSendHeader On
PerlOptions +ParseHeaders Options ExecCGI FollowSymLinks
Includes/Directory
startup.pl
contains:
# This will give
us a stack trace when a perl script dies#$SIG{__WARN__} =
\Carp::cluck;
# Load CGI.pm and
call its compile() method to precompile# (but not to import) its autoloaded
methods.use CGI ();CGI-compile(':all');
use Apache::DBI()
;use DBI() ;
All the scripts run
fine without mod_perl, and in fact ran just fine on the old Apache 1.x system
with mod_perl. I am at the end of my wits on this one and looking for
ideas.
Thanks
dale
Re: RedHat 8.0 standard Apache2.0 and mod_perl 2.0::PerlRun doesn'twork?
Dale Lancaster wrote: I have searched the archives and various websites to find my problem and its associated resolution to no avail. I upgraded my working Apache 1.3 and mod_perl 1.x website using the PerlRun option of modperl to the RedHat 8.0 standard release with Apache/mod_perl 2.0 combo -- bad move it appears. ModPerl::Registry and friends are in beta now. I've ported the 1.0's version and made it a bit more modular via ModPerl::RegistryCooker. It's quite possible that I broke some of the functionalities while porting as you saw in the recent bug fix. The problem is that I couldn't verify whether the porting was 1:1 because there was no exhaustive test suite. For 2.0 we are hoping to have one. First, disable Apache::DBI. Does the problem persist? Second, please download the latest cvs versions of apache and mod_perl and try again. Does the problem persist? If it does, please send a short script that reproduces the problem, and hopefully a self-contained one, so it's not relying on mysql. In short, think of it this way: To solve the problem, I need to reproduce it first. So help me to accomplish that first. __ 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: Release date for mod_perl 2.0
Ask Bjoern Hansen wrote: On 17 Dec 2002, Devin Heitmueller wrote: [...] I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. It will get stable faster if you choose to use it. :-) True, other than porting the remaining APIs, we need your bug reports so those ported can be fixed. Other than that perfork mpm is probably in a pretty good shape. Doug says that a few Covalent's clients use it in production for quite a while. Check whether you have all the APIs that you need available, and if so give it a stress test. You can use Apache::compat for those APIs that for some reason aren't there yet. See: http://perl.apache.org/docs/2.0/user/compat/compat.html p.s. when you test, please use the cvs mod_perl version. We plan to make a new beta release soon, since many things were fixed/added since the last release. __ 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
Release date for mod_perl 2.0
I am starting a new project that makes use of functionality required in Apache 2. Naturally, I would like to use mod_perl, but mod_perl 2.0 is still in beta. Can anyone offer any information about when they feel mod_perl will be stable enough for use in a production environment? I intend to use it with the prefork MPM in Apache, if that has any relevance to how stable mod_perl 2.0 is in that mode (since there should be no multithreading issues). I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. Thanks in advance, -- Devin Heitmueller Senior Software Engineer Netilla Networks Inc
Re: Release date for mod_perl 2.0
On Dec 17 Devin Heitmueller wrote: Can anyone offer any information about when they feel mod_perl will be stable enough for use in a production environment? Sometime next year. See: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/krekrouslor/[EMAIL PROTECTED] Now, back to lurking. Jim
Re: Release date for mod_perl 2.0
On 17 Dec 2002, Devin Heitmueller wrote: [...] I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. It will get stable faster if you choose to use it. :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
So, I have updated my src of apache, arp and mod_perl2 from cvs. Still the exact same result. I've messed up while adjusting for the new libapr's naming. it's fixed now in cvs. Though you shouldn't have had a problem in first place. it'd have just skipped linking to the apr libs and shouldn't have caused a problem. In any case. Please update your cvs version and try again. If you fail, please check that you build against the new versions that you have installed. that's make sure that you've deleted all the old installs, if they are no longer needed. If you still fail, post a complete report as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems __ 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 trouble compiling = cannont find -lapr -laprutil
Hello, Stas, I didn't take offense at your first reply. Steven, I'm sorry if my post was in any way insulting or otherwise offensive. Stas, I do understand - more with every piece of code I add to my box - that the xnix world and esp. the open source core of that world is a constantly shifting one. So, I have updated my src of apache, arp and mod_perl2 from cvs. Still the exact same result. Thanks, Daren Steven Adams [EMAIL PROTECTED] wrote: Is there a reason that we have to be this insulting? Beckman, I really expected more out of you. LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_pe rl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly.
mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
Hello Happy Holidays, I'm also having trouble with mod_perl compiling. I know I risk RTFM replies. I just don't know where else to ask. If I'm missing some already posted info, please point me there and accept my appologies. I'll confess I'm very new to this but I've spent the past six months studying and building and resolving myriad confilcts and dependancies on this server: Red Hat v8.0 Apache v2.0.43 perl v5.8.0 gcc v 3.2 (2002 09 03) mod_perl 2.0 (nee 1.99_07) apr 0.9.1 apr-util 0.9.1 (I must confess that if I hadn't seen the rock-solid stability of xnix OS's I'd have given up long before now. The dependancy ride-go-'round with lib's and versions of gcc and required modules and varying versions of other OS components and programs has left me weary indeed and almost willing to give over the the dark side and consider M$ platforms instead of my LAMPS (Linux Apache MySQL PHP server). Please help a green accolyte keep his faith. The path of the way must challenge in order to foster growth and strength, but it must not crush nor kill.) In addition I've started from a clean install with updates (I do know this can be bad.) downloaded all of these components and updated from cvs today (13 DEC 2002). Yet... I receive the following after ./config'ing mod_perl: # make ... gcc -c -I/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/src/modules/perl -I /usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs -I/usr/local/apache2/2.0.4 3/include -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gd bm -DMOD_PERL -O2 -march=i386 -mcpu=i686 -DVERSION=\0.01\ -DXS_VERSION=\ 0.01\ -fpic -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE APR.c Running Mkbootstrap for APR () chmod 644 APR.bs rm -f ../../../blib/arch/Apache2/auto/APR/APR.so LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 make[3]: Leaving directory `/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs/APR/APR' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/usr/local/src/LAMPS/mod_perl/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 #_ I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. When ./configure'ing the newest apr-util I get: #./configure ... ./configure: line 1278: syntax error near unexpected token `config.nice' ./configure: line 1278: `APR_CONFIG_NICE(config.nice)' #_ Mr. Bekman, can you kindly tell me what you recommend I get the latest cvs of? Did you mean mod_perl, libapr, Apache, or something else, or all of these? What was the broken build of? How do I mend it? I've tried the latest versions of these from CVS but get the same errors. Mr. Jensen, what did - if anything did - solve your problem? Thanks all for your kind consideration and in advance for any help you can provide. Your humble student, Daren Fairbanks
Re: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
D. Fairbanks wrote: [...] LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_perl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly. __ 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 trouble compiling = cannont find -lapr -laprutil
Is there a reason that we have to be this insulting? Beckman, I really expected more out of you. LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_pe rl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly.
Re: make test failed when installing mod_perl 2.0 on Linux
Your attention please: [***] [*** ***] [*** please send the followups back to the list! ***] [*** ***] [***] Thank you! Now to the solutions: Dawn Sun wrote: I've used this patch Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 26 Nov 2002 12:20:03 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init But make test failed again. This time, the error changed from the Can't locate TestHooks/init/first.pm in @INC... to Can't locate TestHooks/trans.pm in @INC Other errors remain the same. Good, so probably adding PerlModule TestHook::trans in a similar way (inside Base/Base of t/hooks/TestHooks/trans.pm) should solve that problem too. Though it should have resolved the handlers automatically. You need to enable PERL_TRACE (see the online docs) and post the trace so we can see why these don't get resolved. __ 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
make test failed when installing mod_perl 2.0 on Linux
Hi I am new to linux and mod_perl. Weare runningperl 5.8.0 and apache 2.0.43 on linux.First time we are tryingtoinstall mod_perl2.But the "make test"failed completed. Here is the error_log reads: END in modperl_extra.pl, pid=19385[Thu Nov 21 11:24:45 2002] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_07-dev Perl/v5.8.0configured -- resuming normal operations[Thu Nov 21 11:24:45 2002] [info] Server built: Nov 20 2002 15:10:20[Thu Nov 21 11:24:45 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem)[Thu Nov 21 11:24:46 2002] [error] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 23) line 3. [Thu Nov 21 11:24:46 2002] [error] failed to resolve handler `TestHooks::init::first'[Thu Nov 21 11:24:46 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pmin @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl- . [Thu Nov 21 11:26:32 2002] [error] failed to resolve handler `TestHooks::init::first'[Thu Nov 21 11:26:34 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 25) line 3. [Thu Nov 21 11:27:27 2002] [error] failed to resolve handler `TestProtocol::echo'[Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl- [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC [Thu Nov 21 11:27:29 2002] [error] failed to resolve handler `TestProtocol::echo_filter'[Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC . [Thu Nov 21 11:27:29 2002] [info] removed PID file /home/dsun/mod_perl-1.99_07/t/logs/httpd.pid (pid=19387)[Thu Nov 21 11:27:29 2002] [notice] caught SIGTERM, shutting downEND in modperl_extra.pl, pid=19387 I've checked the actual module in @INC. It does exist. Then I'vesearched throu the mod_perl archive, and made the change as http://www.mail-archive.com/modperl@apache.org/msg29648.htmlsuggested. But "make test" failed again. This time, the error changed from the "Can't locate TestHooks/init/first.pm in @INC... " to "Can't locate TestHooks/trans.pm in @INC...". Other errors remain the same. Any suggestions? Dawn
Re: make test failed when installing mod_perl 2.0 on Linux
please remember to properly report problems, as explained at: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems (hint: the shortcuts menu on the left side of any page of perl.apache.org) if you don't provide all the required details it makes it hard to guess what configuration you've the problem with. I had this problem a while ago with the worker mpm over 5.8.0: http://marc.theaimsgroup.com/?l=apache-modperl-devm=101128927611980w=2 but I think it should be OK now. I am new to linux and mod_perl. We are running perl 5.8.0 and apache 2.0.43 on linux. First time we are trying to install mod_perl2. But the make test failed completed. Here is the error_log reads: END in modperl_extra.pl, pid=19385 [Thu Nov 21 11:24:45 2002] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 configured -- resuming normal operations [Thu Nov 21 11:24:45 2002] [info] Server built: Nov 20 2002 15:10:20 [Thu Nov 21 11:24:45 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Thu Nov 21 11:24:46 2002] [error] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 23) line 3. [Thu Nov 21 11:24:46 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:24:46 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl- . [Thu Nov 21 11:26:32 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:26:34 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 25) line 3. [Thu Nov 21 11:27:27 2002] [error] failed to resolve handler `TestProtocol::echo' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl- [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC [Thu Nov 21 11:27:29 2002] [error] failed to resolve handler `TestProtocol::echo_filter' [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC . [Thu Nov 21 11:27:29 2002] [info] removed PID file /home/dsun/mod_perl-1.99_07/t/logs/httpd.pid (pid=19387) [Thu Nov 21 11:27:29 2002] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=19387 I've checked the actual module in @INC. It does exist. Then I've searched throu the mod_perl archive, and made the change as http://www.mail-archive.com/modperl@apache.org/msg29648.html suggested. But make test failed again. This time, the error changed from the Can't locate TestHooks/init/first.pm in @INC... to Can't locate TestHooks/trans.pm in @INC Other errors remain the same. Any suggestions? Dawn -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
ApacheCon mod_perl 2.0 presentation's handouts
If you come to ApacheCon and plan to go to the mod_perl 2.0 presentation on Wed, after the lunch, here are the handouts if you want to print them. The conference organizers won't give printed versions, in order to cut costs. So here it's: http://stason.org/talks/apachecon2002/presentation/mod_perl-2.0-presentation-handouts.pdf.gz If you come to my mod_perl 2.0 by example tutorial on Monday, I believe you will be given a printed copy of the handouts, so no need to bring your own copy. Older presentations/tutorials are available at the usual location: http://stason.org/talks/ See you next week. p.s. If you are looking for us Eric and I are staying in the room #1801 at Alexis Park Resort. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Apache::Clean mod_perl 2.0 port
hi all... I had a few moments so I've started to port Apache::Clean over to mod_perl 2.0. it's far from complete, and I haven't examined all the issues with proper caching headers yet, but you can find the work in progress here: http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-Clean-2.00b.tar.gz it's _very_ alpha, so if you have problems, well, consider it an invitation to polish your debugging skills :) I'll be playing with it on and off, though, so feel free to contact me directly about it. the only real issue I noticed is that the 1.3 Apache::Filter and mod_perl 2.0 Apache::Filter don't seem to play nice with PerlModule Apache2, but it could have been something in my setup. I ended up needing to uninstall Ken's old Apache::Filter to make the test suite work. anyway, as I said it's a work in progress, but for those of you who want to play around with the 2.0 API and haven't yet (like me) Apache::Clean is itself a PerlOutputFilterHandler, and the distribution includes a (brief) example of SetHandler modperl and the Apache::Test test suite. have fun. --Geoff
Make test failure when installing mod_perl 2.0 on Solaris 8 with Apache 2
Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: ./configure --enable-layout=Solaris --enable-perl=shared --with-mpm=prefork (as normal user) make(as normal user) make test (as root user) make install (as root user) this seems to install fine. I have then configured mod_perl as follows: perl Makefile.PL MP_AP_PREFIX=/usr/apache MP_INST_APACHE2=1 (as normal user) make (as normal user) make test (as root user) And the 'make test' fails: Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/cgihandler.t22 100.00% 1-2 apache/compat.t33 100.00% 1-3 apache/post.t 21 50.00% 2 apache/read.t 11 100.00% 1 apache/scanhdrs.t 29 7424 44 100.00% 1-4 api/send_fd.t 32 66.67% 2-3 api/sendfile.t 32 66.67% 2-3 directive/perlmodule.t 11 100.00% 1 directive/perlrequire.t11 100.00% 1 directive/setupenv.t 31 33.33% 2 filter/input_body.t22 100.00% 1-2 filter/lc.t11 100.00% 1 hooks/access.t 42 50.00% 2-3 hooks/trans.t 33 100.00% 1-3 modperl/getc.t 21 50.00% 2 modperl/readline.t 21 50.00% 2 modperl/sameinterp.t 29 742412 12 100.00% 1-12 modules/include.t 65 83.33% 1 3-6 protocol/echo.t 255 65280 32 66.67% 2-3 protocol/echo_filter.t 255 65280 32 66.67% 2-3 50 tests skipped. So, as you can see not very good. After looking at the recommended log file (t/logs/errorlog) I see the following: bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/home/software/apache _download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/lib/Apach e2 /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apache2 /export/home/software/apache_download_2_0_39/mod_perl -1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/software/apache_down load_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/p rotocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/perlmodule-vh /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/main /usr/local/lib/perl5/5.8.0/sun4-so laris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr /local/lib/perl5/site_perl) at (eval 15) line 3. [Tue Aug 20 15:01:20 2002] [error] failed to resolve handler `TestHooks::init::first' [Tue Aug 20 15:01:20 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/li b/Apache2 /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apac he2 /export/home/software/apache_downl oad_2_0_39/mod_perl-1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/ arch /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/protocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apach e_download_2_0_39/mod_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irec
Re: Make test failure when installing mod_perl 2.0 on Solaris 8 withApache 2
Tom Hibbert wrote: Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: [...] bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in Try this patch: Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 20 Aug 2002 15:31:18 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init __ 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
silent failure still a problem in mod_perl 2.0?
Kyle Dawkins writes: I'd betcha your problem is almost certainly caused by your use of DSOs. If you *really* want to prune your system down to see where your bug is, then build apache and mod_perl statically. There was a very well-known bug that caused DBI to segfault if it was run under a DSO. Please rebuild your binary and then let us know if that was the problem. I just ran into the silent-failure problem again today, when a sysadmin unknowingly upgraded glibc underneath mod_perl built as a DSO. Unfortunately, it was on a production system; fortunately, it was not on a very important production system, and rebuilding the tools fixed the problem. In anticipation of the postmortem meeting, I'm trying to find out if this problem still exists in mod_perl 2.0. Websearches have been fruitless; any pe[a]rls of wisdom from the list? Charlton
FW: silent failure still a problem in mod_perl 2.0?
Kyle Dawkins writes: I'd betcha your problem is almost certainly caused by your use of DSOs. If you *really* want to prune your system down to see where your bug is, then build apache and mod_perl statically. There was a very well-known bug that caused DBI to segfault if it was run under a DSO. Please rebuild your binary and then let us know if that was the problem. I just ran into the silent-failure problem again today, when a sysadmin unknowingly upgraded glibc underneath mod_perl built as a DSO. Unfortunately, it was on a production system; fortunately, it was not on a very important production system, and rebuilding the tools fixed the problem. In anticipation of the postmortem meeting, I'm trying to find out if this problem still exists in mod_perl 2.0. Websearches have been fruitless; any pe[a]rls of wisdom from the list? Charlton
Re: mod_perl 2.0 api and extending method in Apache
Alexandre Dulaunoy wrote:
Hello,
I have look around the documentation of mod_perl 2.0 and I'm looking if
it's possible with the current mod_perl API to add a method (like GET,
HEAD) in apache to extend the functionnaly of the HTTP server ?
There is also some possibility with the new framework to add new protocol
(like the echo example in the mod_perl doc). But I just want to extend
existing (or add new) method... Is it possible ?
I'm not sure what you mean by extending, but look at mod_dav which
extends the HTTP protocol: modules/dav/main/mod_dav.c (inside the
httpd-2.0 repository).
In mod_perl 2.0 you can support new request methods, by simply
registering them. e.g. let's support the method 'TNT' in the response
handler:
Location /extend
SetHandler perl-script
PerlResponseHandler Apache::Extend
/Location
package Apache::Extend;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Const -compile = 'OK';
use constant METHNAME = 'TNT';
sub handler {
my $r = shift;
$r-content_type('text/plain');
Apache::method_register($r-pool, METHNAME);
print Called with Method: . $r-method;
Apache::OK;
}
1;
Now, let's call:
perl -le 'require LWP::UserAgent; print
LWP::UserAgent-new-request(HTTP::Request-new(GET,
http://localhost:8002/extend/;))-content;'
Called with Method: GET
__
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
Problem: Apache2 / Perl 5.8.0 / mod_perl 2.0 / PHP all on Win32
I am in a bit of a jam. I think the cross-post is necessary since I need the help of Apache, mod_perl, and PHP developers/users. I apologize for the length, if you have time, my explanation (at the end) should clarify what I mean. Summary --- I need: - A perl-enabled web server to run on the win32 platform - mod_perl to allow for persistent (stay connected on the server side) Net::Telnet objects (CGI is unacceptable since a new process is spawned at each request leaving no room for persistent objects) - Multiple perl interpreters of Apache2 / mod_perl 2.0 to serve more than one mod_perl request at a time - Access to the client's Net::Telnet object during all of his/her requests throughout his/her session - I might need Perl 5.8.0 for threads::shared to solve the above problem - A way for mod_perl scripts to communicate with PHP scripts quickly and efficiently Does anybody know what kind of configuration I could use to support all of my needs above? Does anybody know another way for mod_perl 2.0 and PHP to communicate other than apache_notes (if it's true I can't use apache_notes with Apache2 / PHP 4.2.X)? If a solution is not available now (ie. I can't share Net::Telnet objects in different requests, or, PHP isn't fully supporting Apache2), when will it be available (if ever)? Thanks for your time and any help, Shawn Brief (?) Explanation - I need a win32 server to provide a sort of web-interface to perl Net::Telnet objects (which is just a wrapper for telnet sessions written in perl). These objects open sockets/file_handles on the server and have to be accessible to my server-side scripts throughout multiple client requests. ie. A session for Client_123 might look like: Request 1: Client_123's telnet object is initialized (connects to a remote telnet host) Request 2 - n-1: A script on the server executes commands on Client_123's telnet connection Request n: Client_123's telnet object is destroyed From mod_perl 2.0 docs (http://perl.apache.org/docs/2.0/os/win32/install.html): A mod_perl 1.0 enabled server based on Apache 1.3 on Win32 is limited to a single thread serving a request at a time. This effectively prevents concurrent processing, which can have serious implications for busy sites. This problem is addressed in the multi-thread/multi-process approach of mod_perl 2.0/Apache 2.0 Obviously I need Apache2/mod_perl2 if I want to be able to have more than one client request executing perl code at the same time. However, I need to make sure that the Net::Telnet object is accessible (ie. in shared memory, indexed by the clients session_id) for all of Client_123's request. I was told that I might be able to use threads::shared to keep the Net::Telnet objects accessible by multiple mod_perl threads in mod_perl2 and Perl 5.8.0 so that shouldn't be a problem... as long as I use Apache2 / mod_perl 2.0 / Perl 5.8.0. Thrown in to the mix is the fact that I need some PHP scripts to communicate (transfer parameters) to mod_perl scripts, and for the mod_perl to transfer the results back to the PHP scripts. I have this working using apache notes in Apache1.3.26 / mod_perl 1.27 / PHP 4.21. However (as mentioned above) only one mod_perl request (involving telnet stuff) can be served at a time so I need to upgrade to Apache2, where there isn't apache_note support (http://bugs.php.net/bug.php?id=17557).
POST_MAX and mod_perl ~2.0
To alter the allowable size of posted material under mod_perl 1.3x you would
use this:
use Apache::compat;
use Apache::Request;
handler
{
my $r = shift;
my $apr = Apache::Request-new($r, POST_MAX=(10*1024));
$apr-args; #get your params here...
}
What is the suggested technique for mod_perl 2.0?
I understand that Apache::Request is replaced with Apache::RequestRec and
Apache::RequestIO and Apache::Request does not compile with a complaint of
Can't locate object method boot via package mod_perl::boot at
C:/Perl/site/lib/Apache/Table.pm line 6. I seem to be running into a 1024
limit on urlencoded POSTs with my current configuration.
Charles
Apache/2.0.37-dev (Win32) mod_perl/1.99_02-dev Perl/v5.6.1
Re: Apache::compat was Apache::DBI with mod_perl 2.0
Ok, I went and installed Apache from CVS this time, but it looks like that installed 2.0.40-dev and I'm still getting errors during make test of mod_perl 2. Does it have to be 2.0.39 specifically to compile? Sorry if I'm just not getting it... -Zac using Apache/2.0.40-dev (prefork MPM) [Thu Jun 27 03:43:52 2002] [info] 20 Apache:: modules loaded [Thu Jun 27 03:43:52 2002] [info] 5 APR:: modules loaded [Thu Jun 27 03:43:52 2002] [info] base server + 5 vhosts ready to run tests [Thu Jun 27 03:43:54 2002] [info] 19 Apache:: modules loaded [Thu Jun 27 03:43:54 2002] [info] 5 APR:: modules loaded [Thu Jun 27 03:43:54 2002] [info] base server + 5 vhosts ready to run tests waiting for server to start: ok (waited 10 secs) server localhost.localdomain:8529 started server localhost.localdomain:8530 listening (TestDirective::perlmodule) server localhost.localdomain:8531 listening (TestDirective::perlrequire) server localhost.localdomain:8532 listening (TestProtocol::echo) server localhost.localdomain:8533 listening (TestProtocol::echo_filter) server localhost.localdomain:8534 listening (TestFilter::input_msg) apache/cgihandlerok apache/compatok apache/compat2...ok apache/conftree..ok apache/constants.ok apache/post..ok apache/read..ok apache/scanhdrs..ok apache/subprocessok apache/write.ok api/access...ok api/aplogok api/conn_rec.ok api/lookup_uri...ok api/lookup_uri2..ok api/module...ok api/r_subclass...ok api/request_rec..ok api/response.ok api/rutilok api/send_fd..ok 2/3# Failed test 3 in api/send_fd.t at line 23 api/send_fd..FAILED test 3 Failed 1/3 tests, 66.67% okay api/sendfile.ok 2/3# Failed test 3 in api/sendfile.t at line 23 api/sendfile.FAILED test 3 Failed 1/3 tests, 66.67% okay api/server_rec...ok api/server_util..ok api/uri..ok apr/base64...ok apr/constantsok apr/date.ok apr/netlib...ok apr/os...ok apr/perlio...skipped all skipped: no reason given apr/pool.ok apr/string...ok apr/tableok apr/util.ok apr/uuid.ok directive/envok directive/perlmodule.ok directive/perlrequireok directive/setupenv...ok filter/api...ok filter/buckets...ok filter/input_bodyok filter/input_msg.ok filter/lcok filter/reverse...ok hooks/access.NOK 2# Failed test 2 in hooks/access.t at line 15 hooks/access.FAILED test 2 Failed 1/4 tests, 75.00% okay hooks/authen.ok 1/4# Failed test 2 in /opt2/src/mod_perl-1.99_04/Apache-Test/lib/Apache/Test.pm at line 46 fail #2 hooks/authen.NOK 2# Failed test 3 in /opt2/src/mod_perl-1.99_04/Apache-Test/lib/Apache/Test.pm at line 46 fail #3 hooks/authen.FAILED tests 2-3 Failed 2/4 tests, 50.00% okay hooks/authz..NOK 2# Failed test 2 in hooks/authz.t at line 15 # Failed test 3 in hooks/authz.t at line 17 hooks/authz..FAILED tests 2-3 Failed 2/4 tests, 50.00% okay hooks/fixup..ok hooks/headerparser...ok hooks/init...ok hooks/trans..# Failed test 1 in hooks/trans.t at line 12 hooks/trans..FAILED test 1 Failed 1/3 tests, 66.67% okay modperl/dir_config...ok modperl/endavok modperl/env..ok modperl/exit.ok modperl/getc.ok modperl/method...ok modperl/methodname...ok modperl/methodobjok modperl/pnotes...ok modperl/printok modperl/printf...ok modperl/readline.ok modperl/sameinterp...ok modperl/subenv...ok modules/cgi..ok modules/cgiuploadok modules/include..ok protocol/echook protocol/echo_filter.ok Failed TestStat Wstat Total Fail Failed List of Failed --- api/send_fd.t 31 33.33% 3 api/sendfile.t31 33.33% 3 hooks/access.t41 25.00% 2 hooks/authen.t42 50.00% 2-3 hooks/authz.t 42 50.00% 2-3 hooks/trans.t 31 33.33% 1 1 test skipped. *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) make: *** [run_tests] Error 1 - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Sent: Thursday, June 27, 2002 2:33 AM Subject: Re: Apache::compat was Apache::DBI with mod_perl 2.0 errors: using Apache/2.0.36 (prefork MPM) because you must use 2.0.39
Re: Apache::compat was Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, I went and installed Apache from CVS this time, but it looks like that installed 2.0.40-dev and I'm still getting errors during make test of mod_perl 2. Does it have to be 2.0.39 specifically to compile? Yes, to compile 1.99_04 Sorry if I'm just not getting it... It's easy: * httpd is changing all the time * Perl is changing too * mod_perl uses both APIs and therefore depends on the above two in order to give you a version where mod_perl uses the right APIs from httpd and Perl, we say the versions that you've to use. Now if you go for the cvs versions, chances are that we didn't have a chance to update mod_perl to the latest cvs changes in httpd, perl or both. And this is the case that you hit. get 5.8.0-RC2 and 2.0.39 and then 1.99_04 will compile and pass all tests 100%. __ 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: Apache::compat was Apache::DBI with mod_perl 2.0
Ok, I understand. Maybe some kind of message/logic in the make to tell you that you have to have specifically x, y, z. Because I honestly DID hear you say x, y, z but my brain assumed x+, y+, z+ Just a thought. Thanks, -Zac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Cc: mod_perl [EMAIL PROTECTED] Sent: Thursday, June 27, 2002 6:08 AM Subject: Re: Apache::compat was Apache::DBI with mod_perl 2.0 Zac Morris wrote: Ok, I went and installed Apache from CVS this time, but it looks like that installed 2.0.40-dev and I'm still getting errors during make test of mod_perl 2. Does it have to be 2.0.39 specifically to compile? Yes, to compile 1.99_04 Sorry if I'm just not getting it... It's easy: * httpd is changing all the time * Perl is changing too * mod_perl uses both APIs and therefore depends on the above two in order to give you a version where mod_perl uses the right APIs from httpd and Perl, we say the versions that you've to use. Now if you go for the cvs versions, chances are that we didn't have a chance to update mod_perl to the latest cvs changes in httpd, perl or both. And this is the case that you hit. get 5.8.0-RC2 and 2.0.39 and then 1.99_04 will compile and pass all tests 100%. __ 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: Apache::compat was Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, I understand. Maybe some kind of message/logic in the make to tell you that you have to have specifically x, y, z. Because I honestly DID hear you say x, y, z but my brain assumed x+, y+, z+ I've updated the README file, which now states what you need. All the troubles will go away, after perl 5.8.0 (RSN) and Apache 2.0 (ASAP) will freeze their APIs and be released. __ 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: Apache::compat was Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, still getting the same errors during make test. One of the first lines of the perl Makefile.PL --blahblah shows: Configuring Apache/2.0.39 mod_perl/1.99_04 Perl/v5.8.0 Does this mean that the make install I did on the Perl/v5.8.0_RC2 didn't take? may be you didn't install it after the build? I suggest installing everything into a new location so there will be no doubts. Just to test. just write a script that does all the work so you don't have to waste time. you can ignore the 'make test' in the perl source which is very long (assuming that it works for you) When I perl --version should it show me 5.8.0 RC2? nope. it shows 5.8.0 __ 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: 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: 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: Apache::DBI with mod_perl 2.0
Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? Thanks, -Zac
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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: Apache::DBI with mod_perl 2.0
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? 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? Thanks for all this info, learning more and more every day. :) -Zac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 11:02 AM Subject: Re: Apache::DBI with mod_perl 2.0 Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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: 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.pm4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm25 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: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 00:49 23.06.2002, Charles Aulds wrote: At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Great! Seems like Apache::compat is working as a charm. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Server Version: Apache/2.0.36 (Unix) mod_perl/1.99_03-dev Perl/v5.6.1 DAV/2 Using Per Ellesfsen's suggests, and also pre-loading the following startup.pl script (for compat.pm): #!/usr/bin/perl -w use strict; use Apache2(); use Apache::compat; 1; Rudimentary benchmarks, using a MySQL server, and very simple query, shows that Apache::DBI significantly reduces user response time, and increases the throughput of the server (a very limited single P200 MX system, with only 64MB RAM running RH 7.3): Table 8.2: Benchmarking Results Using Database Connection Sharing CGImod_perl Server Hostname192.168.1.1192.168.1.1 Server Port8080 Document Path/cgi-bin/zipcodes.cgi?zip=35801/perl/zipcodes.cgi?zip=35801 Concurrency Level1010 Elapsed Time258.722seconds63.691 seconds Complete Requests200200 Failed Requests00 Total Transferred127000 bytes131843 bytes HTML Transferred89200 bytes90200 bytes Requests per Second0.773.20 Median Connection Times 12518 ms424 ms Transfer Rate0.48Kbps received2.05Kbps received --- Charles Aulds, MCSE, MCP+I Voice: (256) 931-5593 Fax: (240) 352-8290 http://hiwaay.net/~caulds
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Server Version: Apache/2.0.36 (Unix) mod_perl/1.99_03-dev Perl/v5.6.1 DAV/2 Using Per Ellesfsen's suggests, and also pre-loading the following startup.pl script (for compat.pm): #!/usr/bin/perl -w use strict; use Apache2(); use Apache::compat; 1; Rudimentary benchmarks, using a MySQL server, and very simple query, shows that Apache::DBI significantly reduces user response time, and increases the throughput of the server (a very limited single P200 MX system, with only 64MB RAM running RH 7.3): CGImod_perl Server Hostname192.168.1.1192.168.1.1 Server Port8080 Document Path/cgi-bin/zipcodes.cg /perl/zipcodes.cgi? zip=35801 zip=35801 Concurrency Level1010 Elapsed Time258.722seconds63.691 seconds Complete Requests200200 Failed Requests00 Total Transferred127000 bytes131843 bytes HTML Transferred89200 bytes90200 bytes Requests per Second0.773.20 Median Connection Times 12518 ms424 ms Transfer Rate0.48Kbps received2.05Kbps received --- Charles Aulds, MCSE, MCP+I Voice: (256) 931-5593 Fax: (240) 352-8290 http://hiwaay.net/~caulds
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). You will probably also want to see the 2.0 docs at http://perl.apache.org/release/docs/ Good luck! -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
Per Einar Ellefsen wrote: At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules in your httpd.conf, before loading other modules (like Apache::DBI). You will probably also want to see the 2.0 docs at http://perl.apache.org/release/docs/ start here: http://perl.apache.org/release/docs/2.0/user/intro/start_fast.html but since it seems that you've it installed already, proceed here: http://perl.apache.org/release/docs/2.0/user/config/config.html#Enabling_mod_perl though I haven't tried, you should be able to use Apache::DBI with the compat layer and preforked mpm/ __ 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: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules Nope, he did a clean mod_perl 2 install, without MP_INST_APACHE2 I think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed before. ah, ok then, but most likely MP_INST_APACHE2 is going to be the default, so if later you need to install mod_perl 1.0 you don't have to wipe your 2.0 install first. so better start getting used to it :) -- __ 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: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 19:46 21.06.2002, Stas Bekman wrote: Per Einar Ellefsen wrote: At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules Nope, he did a clean mod_perl 2 install, without MP_INST_APACHE2 I think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed before. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: mod_perl 2.0 - writing a proxy handler
On Tue, 14 May 2002, Douglas Younger wrote:
Hello,
Has anyone written a proxy handler in 2.0 similar to example 7-12 of the
O`Reilly book? I've tried converting it without much luck. I don't need the
add-blocker stuff, just a generic proxy handle that I can add some
additional lines to parse the output.
you'll need modperl from cvs (or wait for _02) for $r-proxyreq to
auto-detect a proxy request. with modperl-cvs and Apache::compat loaded,
i have run Apache::AdBlocker without any modperl api changes. however, i
did need the patch below because my GD install does have gif support.
--- lib/Apache/AdBlocker.pm~Fri Mar 3 21:08:35 2000
+++ lib/Apache/AdBlocker.pm Mon May 20 17:31:22 2002
-61,7 +61,7
my $content = \$response-content;
if($r-content_type =~ /^image/ and $r-uri =~ /\b($Ad)\b/i) {
block_ad($content);
- $r-content_type(image/gif);
+ $r-content_type(image/png);
}
$r-content_type('text/html') unless $$content;
-85,7 +85,7
$im-string(GD::gdLargeFont(),5,5,Blocked Ad,$red);
$im-rectangle(0,0,$x-1,$y-1,$black);
-$$data = $im-gif;
+$$data = $im-png;
}
1;
mod_perl 2.0 - writing a proxy handler
Hello, Has anyone written a proxy handler in 2.0 similar to example 7-12 of the O`Reilly book? I've tried converting it without much luck. I don't need the add-blocker stuff, just a generic proxy handle that I can add some additional lines to parse the output. I've had some problems with Apache's default mod_proxy so I'd like to just do everything with mod_perl. (problems include chunked data and empty pages) Thanks! -Doug
Re: Fw: How do I determine end of request? (mod_perl 2.0)
Hello, Thanks for the suggestion, but it doesn't seem to make any difference. I tried setting: ProxyIOBufferSize 32768 ProxyReceiveBufferSize 32768 in my httpd.conf, and it is still calling my handler several times per request... I put in: warn Size: . length($buffer) . \n; in my while ($filter-read) loop and get the following for a single page (page is ~11k): Size: 1101 Size: 3109 Size: 987 Size: 4096 Size: 1697 (Before I increased my buffer size in the read it would break down the larger of the above into further chunks.) I think the best way would be to somehow determine where the actual end of the document is to call $p-eof;. Because even if increasing the various buffers worked, I don't want to make them insanely large, but I could end up having pages larger than the buffer, which would leave me with problems again. I'd rather not use a solution like looking for /html as I need to use this for .css and other non-html files. Also, some of the proxied documents use SSI and may contain multiple instances of /HTML. (I tested it by checking for /html and then calling $p-eof; and it does solve the problem, but as I explained this is not an ideal solution.) At 11:34 PM 5/6/2002 +0200, pascal barbedor wrote: hi you could maybe set the ProxyIOBufferSize or Proxyreceivebuffersize in the front end server so that response from modperl server would not be chunked but one shot also static ressources like gif in server B documents could be retrieved from server A only with an alias not proxied to server B pascal - Original Message - From: Douglas Younger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 06, 2002 10:26 PM Subject: How do I determine end of request? (mod_perl 2.0) Hello, I'm fairly new to using mod_perl. I've been able to find lots of resources dealing with mod_perl 1.x, but the documentation for 2.0 is rather sparse. I'm pretty sure what I need to do can only be handled by Apache 2.0 thus I'm forced to use mod_perl 2.0... (well 1.99) I'm trying to proxy ServerB through ServerA... ok that's simple enough with mod_proxy. However, links, embedded images, etc in the proxied document end up broken if they are non-relative links (ie. start with a slash). Example: on ServerB is a document say: /sales/products.html in products.html it links to /images/logo.gif accessing /sales/products.html using ServerB everything is fine. But, if I want to proxy ServerB via ServerA... say ProxyPass /EXTERNAL http://ServerB If I goto http://ServerA/EXTERNAL/sales/products.html the embedded image /images/logo.gif is requested from ServerA. So to handle this I wanted to write a filer for ServerA to parse all pages served via Location /EXTERNAL and fix the links. I wrote a handler (see below) using HTML::Parser to extract the tags that would contain links and process them. It works great for the most part... however, it seems like instead of ServerA getting the entire output from ServerB, it gets it in chunks which get processed individually. This causes my handler to fail when a tag is split between 2 chunks. What I think needs to be done is to build up the document in a variable $html .= $buffer; and then call the $p-$parse($html) once the entire document has been received by ServerA (or maybe as simple of only calling $p-eof; at that point). Or is there a better way to do this? One problem I've found so far is I need to fix style sheets, but I can probably write a special handler for them once I get this problem fixed. Thanks!
How do I determine end of request? (mod_perl 2.0)
Hello,
I'm fairly new to using mod_perl. I've been able to find lots of
resources dealing with mod_perl 1.x, but the documentation for 2.0 is
rather sparse.
I'm pretty sure what I need to do can only be handled by Apache 2.0 thus
I'm forced to use mod_perl 2.0... (well 1.99)
I'm trying to proxy ServerB through ServerA... ok that's simple enough with
mod_proxy. However, links, embedded images, etc in the proxied document end
up broken if they are non-relative links (ie. start with a slash).
Example: on ServerB is a document say: /sales/products.html
in products.html it links to /images/logo.gif
accessing /sales/products.html using ServerB everything is fine. But, if I
want to proxy ServerB via ServerA... say
ProxyPass /EXTERNAL http://ServerB
If I goto http://ServerA/EXTERNAL/sales/products.html the embedded image
/images/logo.gif is requested from ServerA.
So to handle this I wanted to write a filer for ServerA to parse all pages
served via Location /EXTERNAL and fix the links.
I wrote a handler (see below) using HTML::Parser to extract the tags that
would contain links and process them.
It works great for the most part... however, it seems like instead of
ServerA getting the entire output from ServerB, it gets it in
chunks which get processed individually. This causes my handler to fail
when a tag is split between 2 chunks.
What I think needs to be done is to build up the document in a variable
$html .= $buffer; and then call the $p-$parse($html) once the entire
document has been received by ServerA (or maybe as simple of only calling
$p-eof; at that point).
Or is there a better way to do this? One problem I've found so far is I
need to fix style sheets, but I can probably write a special handler for
them once I get this problem fixed.
Thanks!
##
package RewriteLinks;
use strict;
use Apache::Filter;
use Apache::RequestUtil;
use APR::Table;
use HTML::Parser;
my %ReplaceAttrs = ( a = 'href',
img = 'src',
link = 'href',
td= 'background',
form = 'action'
);
my $filter;
sub handler {
$filter = shift;
### Create parser object ###
my $p = HTML::Parser-new( api_version = 3 );
$p-handler(start = \do_tags, 'tagname, attr, text' );
$p-handler(default = \default, 'text');
while ($filter-read(my $buffer, 32678)) {
$p-parse($buffer);
}
$p-eof; # signal end of document
1;
}
sub do_tags {
my ($tagname, $attr, $text) = _;
## only need to modify tags with url-like attributes starting with a slash
if ($$attr{$ReplaceAttrs{$tagname}} =~ m|^/|) {
my $TAG = . uc($tagname);
foreach my $key (keys %$attr) {
$TAG .= ' ' . uc($key) . '=';
if ($key eq $ReplaceAttrs{$tagname}) {
$TAG .= '/EXTERNAL';
}
$TAG .= $$attr{$key} . '';
}
$TAG .= \n;
$filter-print($TAG);
} else {
$filter-print($text);
}
}
sub default {
my ($text) = _;
$filter-print($text);
}
1;
Fw: How do I determine end of request? (mod_perl 2.0)
- Original Message -
From: pascal barbedor [EMAIL PROTECTED]
To: Douglas Younger [EMAIL PROTECTED]
Sent: Monday, May 06, 2002 11:31 PM
Subject: Re: How do I determine end of request? (mod_perl 2.0)
hi
you could maybe set the ProxyIOBufferSize
or Proxyreceivebuffersize
in the front end server so that response from modperl server would not be
chunked but one shot
also static ressources like gif in server B documents could be retrieved
from server A only with an alias not proxied to server B
pascal
- Original Message -
From: Douglas Younger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 06, 2002 10:26 PM
Subject: How do I determine end of request? (mod_perl 2.0)
Hello,
I'm fairly new to using mod_perl. I've been able to find lots of
resources dealing with mod_perl 1.x, but the documentation for 2.0 is
rather sparse.
I'm pretty sure what I need to do can only be handled by Apache 2.0
thus
I'm forced to use mod_perl 2.0... (well 1.99)
I'm trying to proxy ServerB through ServerA... ok that's simple enough
with
mod_proxy. However, links, embedded images, etc in the proxied document
end
up broken if they are non-relative links (ie. start with a slash).
Example: on ServerB is a document say: /sales/products.html
in products.html it links to /images/logo.gif
accessing /sales/products.html using ServerB everything is fine. But, if
I
want to proxy ServerB via ServerA... say
ProxyPass /EXTERNAL http://ServerB
If I goto http://ServerA/EXTERNAL/sales/products.html the embedded image
/images/logo.gif is requested from ServerA.
So to handle this I wanted to write a filer for ServerA to parse all
pages
served via Location /EXTERNAL and fix the links.
I wrote a handler (see below) using HTML::Parser to extract the tags
that
would contain links and process them.
It works great for the most part... however, it seems like instead of
ServerA getting the entire output from ServerB, it gets it in
chunks which get processed individually. This causes my handler to
fail
when a tag is split between 2 chunks.
What I think needs to be done is to build up the document in a variable
$html .= $buffer; and then call the $p-$parse($html) once the entire
document has been received by ServerA (or maybe as simple of only
calling
$p-eof; at that point).
Or is there a better way to do this? One problem I've found so far is I
need to fix style sheets, but I can probably write a special handler for
them once I get this problem fixed.
Thanks!
##
package RewriteLinks;
use strict;
use Apache::Filter;
use Apache::RequestUtil;
use APR::Table;
use HTML::Parser;
my %ReplaceAttrs = ( a = 'href',
img = 'src',
link = 'href',
td= 'background',
form = 'action'
);
my $filter;
sub handler {
$filter = shift;
### Create parser object ###
my $p = HTML::Parser-new( api_version = 3 );
$p-handler(start = \do_tags, 'tagname, attr, text' );
$p-handler(default = \default, 'text');
while ($filter-read(my $buffer, 32678)) {
$p-parse($buffer);
}
$p-eof; # signal end of document
1;
}
sub do_tags {
my ($tagname, $attr, $text) = @_;
## only need to modify tags with url-like attributes starting with a
slash
if ($$attr{$ReplaceAttrs{$tagname}} =~ m|^/|) {
my $TAG = . uc($tagname);
foreach my $key (keys %$attr) {
$TAG .= ' ' . uc($key) . '=';
if ($key eq $ReplaceAttrs{$tagname}) {
$TAG .= '/EXTERNAL';
}
$TAG .= $$attr{$key} . '';
}
$TAG .= \n;
$filter-print($TAG);
} else {
$filter-print($text);
}
}
sub default {
my ($text) = @_;
$filter-print($text);
}
1;
Apache 2.0 gold -- now when mod_perl 2.0?
It looks like Apache 2.0(.35) is 'gold', so when can we expect a 'gold' version of mod_perl 2.0 so we can actually make apache 2 fun? ;p Jon Coulter [EMAIL PROTECTED]
Re: Status of mod_perl 2.0
Which gives me another nice idea for articles... How about some pointers in thread safety with Apache/Perl... What you sould and should not do? Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Jeff Stuart [EMAIL PROTECTED] Cc: Mod Perl Devel List [EMAIL PROTECTED]; Mod perl mailing list [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 8:00 PM Subject: Re: Status of mod_perl 2.0 Jeff Stuart wrote: Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all? Tell me what's the status of apache 2.0 and I'll tell you the status of mod_perl 2.0 :) But seriously mod_perl 2.0 will be ready about the time apache 2.0 (i.e. httpd-2.0) gets released. You can start playing with it already. I've successfully run my singlesheaven.com code using mod_perl 2.0 a few months ago. And there are many tests, so you can see what works and what not. Registry is almost completed, a few thread-safety issues unresolved (e.g. chdir() in the threaded env). If you plan on adding a testing platform for you product, make sure to use the Apache::Test framework from 2.0 distro, which rocks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of mod_perl 2.0
On Wed, 2002-02-27 at 13:00, Stas Bekman wrote: Jeff Stuart wrote: Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all? Tell me what's the status of apache 2.0 and I'll tell you the status of mod_perl 2.0 :) But seriously mod_perl 2.0 will be ready about the time apache 2.0 (i.e. httpd-2.0) gets released. You can start playing with it already. I've successfully run my singlesheaven.com code using mod_perl 2.0 a few months ago. And there are many tests, so you can see what works and what not. Registry is almost completed, a few thread-safety issues unresolved (e.g. chdir() in the threaded env). If you plan on adding a testing platform for you product, make sure to use the Apache::Test framework from 2.0 distro, which rocks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ Heh... status of Apache 2.0? WHO Knows? LOL
Re: Status of mod_perl 2.0
Issac Goldstand wrote: Which gives me another nice idea for articles... How about some pointers in thread safety with Apache/Perl... What you sould and should not do? please refer to the [EMAIL PROTECTED] list archives, there were quite long discussions there. Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Jeff Stuart [EMAIL PROTECTED] Cc: Mod Perl Devel List [EMAIL PROTECTED]; Mod perl mailing list [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 8:00 PM Subject: Re: Status of mod_perl 2.0 Jeff Stuart wrote: Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all? Tell me what's the status of apache 2.0 and I'll tell you the status of mod_perl 2.0 :) But seriously mod_perl 2.0 will be ready about the time apache 2.0 (i.e. httpd-2.0) gets released. You can start playing with it already. I've successfully run my singlesheaven.com code using mod_perl 2.0 a few months ago. And there are many tests, so you can see what works and what not. Registry is almost completed, a few thread-safety issues unresolved (e.g. chdir() in the threaded env). If you plan on adding a testing platform for you product, make sure to use the Apache::Test framework from 2.0 distro, which rocks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Status of mod_perl 2.0
Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all?
Re: Status of mod_perl 2.0
Jeff Stuart wrote: Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all? Tell me what's the status of apache 2.0 and I'll tell you the status of mod_perl 2.0 :) But seriously mod_perl 2.0 will be ready about the time apache 2.0 (i.e. httpd-2.0) gets released. You can start playing with it already. I've successfully run my singlesheaven.com code using mod_perl 2.0 a few months ago. And there are many tests, so you can see what works and what not. Registry is almost completed, a few thread-safety issues unresolved (e.g. chdir() in the threaded env). If you plan on adding a testing platform for you product, make sure to use the Apache::Test framework from 2.0 distro, which rocks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: knowledge base - was Re: RFC: mod_perl 2.0 documentation project
On Wed, 8 Aug 2001, Jim Smith wrote: On Wed, Aug 08, 2001 at 10:45:43AM +0800, Stas Bekman wrote: On Tue, 7 Aug 2001, Jim Smith wrote: On Tue, Aug 07, 2001 at 10:16:26PM +0800, Stas Bekman wrote: Just some pseudo-random ideation boiling down to let's use mod_perl to buils a knowledge base both to demonstrate it's power and to serve the community. I like the idea!!! If we can come up with a proposal for a generic knowledge base product that would be useful in an IT environment, I can probably devote some of my work to it -- this is something I've been wanting to put together at work for customers and our help desk people but haven't had time yet to get it all together. I'll have more time in September after the students return. go ahead and be the first to propose Jim :) Ok... here are some of my initial thoughts. We need to be able to enter arbitrary documents, so I suggest DocBook as the standard format. This handles articles, books, reference pages, etc., in a well-defined manner. It also allows us to transform to other formats without much of a problem. We can even consider AxKit for at least part of the web interface. We would want to have different sections for documents that are not related. For example, we (here at TAMU) could use a section on Unix, another on Mac, and yet another on Windows systems. Or we could divide it up by services. The different sections would not expect overlap in keyword - content mapping, so we could have an AI::Catagorize object for each section that could provide a default set of keywords. As we entered documents, those objects could learn which keywords were appropriate. We would want to have documents in multiple catagories. This might require the person entering the document enter multiple sets of keywords, one per section. We would need to index on keyword so people could quickly find the documents. Perhaps even a catelogue-style interface for browsing that would be based on keyword categories. This would require some work. (Broad categories are indicated by the presence of certain keywords, or by a weighted average so a document having all but a couple of the appropriate keywords won't be dropped from that category.) Documents shouldn't have to be entered via the web interface, though they could be. We could provide a set of web-page templates for each of the DocBook formats (well, the small ones anyway - don't want to write a book via a web interface). Might want to even integrate with WebDAV and a repository. We probably want to set up a SourceForge project if this is a go. Any ideas on names? This all sounds cool. I have a few concerns with this proposal: - source documents living under modperl cvs are to be written in POD. The project that you suggest should be able to accept this and other formats as a source. Afterwards it can convert it to many other formats. Matt has already done some work on porting PODs into XML. - where the actual converted knowledge base will be hosted? I mean who will host the production version? It's possible that we can get a machine at apache.org, but this is one of the things to worry about. If things need to be dynamically generated, we cannot do this from the same machine the modperl-site is hosted on (daedalus). - we need someone to commit to lead the project, or things would never take off just like it has happened before. Now to see if I can get my boss to support me spending time on such a project :) I hope he does. Really! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: knowledge base - was Re: RFC: mod_perl 2.0 documentation project
On Thu, Aug 09, 2001 at 07:31:11PM +0800, Stas Bekman wrote: This all sounds cool. I have a few concerns with this proposal: - source documents living under modperl cvs are to be written in POD. The project that you suggest should be able to accept this and other formats as a source. Afterwards it can convert it to many other formats. Matt has already done some work on porting PODs into XML. I don't see this as a problem. I was just picking a format out of the air as a starting point. TMTOWTDI and PCDAA (Perl Can Do Almost Anything). - where the actual converted knowledge base will be hosted? I mean who will host the production version? It's possible that we can get a machine at apache.org, but this is one of the things to worry about. If things need to be dynamically generated, we cannot do this from the same machine the modperl-site is hosted on (daedalus). I can't answer that at the moment. - we need someone to commit to lead the project, or things would never take off just like it has happened before. Well, I can lead the code development, but I can't commit to anything more than that at the moment. I won't be able to do even that until after the semester starts (classes start 27 Aug, we have several things to get done before then). Now to see if I can get my boss to support me spending time on such a project :) I hope he does. Really! He was very receptive yesterday evening. Wants to see a proposal (what TAMU would be committing to) before giving the final go ahead. We will probably need to involve our helpdesk people in some of the user-interface design. We will need a design document before coding so we know what we're aiming at. I can lead on that. --James
Re: knowledge base - was Re: RFC: mod_perl 2.0 documentation project
On Thu, 9 Aug 2001, Jim Smith wrote: On Thu, Aug 09, 2001 at 07:31:11PM +0800, Stas Bekman wrote: This all sounds cool. I have a few concerns with this proposal: - source documents living under modperl cvs are to be written in POD. The project that you suggest should be able to accept this and other formats as a source. Afterwards it can convert it to many other formats. Matt has already done some work on porting PODs into XML. I don't see this as a problem. I was just picking a format out of the air as a starting point. TMTOWTDI and PCDAA (Perl Can Do Almost Anything). that's cool. - where the actual converted knowledge base will be hosted? I mean who will host the production version? It's possible that we can get a machine at apache.org, but this is one of the things to worry about. If things need to be dynamically generated, we cannot do this from the same machine the modperl-site is hosted on (daedalus). I can't answer that at the moment. We can start worrying about that later, once we get something to show. I hope ASF can support that and may be use this project for other ASF projects if something really cool and/or useful will be produced. - we need someone to commit to lead the project, or things would never take off just like it has happened before. Well, I can lead the code development, but I can't commit to anything more than that at the moment. I won't be able to do even that until after the semester starts (classes start 27 Aug, we have several things to get done before then). Oh, that's absolutely fine. We aren't in hurry at all. We have not many docs written yet anyway. This is something that we should do in parallel with the actual docs writing. Now to see if I can get my boss to support me spending time on such a project :) I hope he does. Really! He was very receptive yesterday evening. Wants to see a proposal (what TAMU would be committing to) before giving the final go ahead. We will probably need to involve our helpdesk people in some of the user-interface design. We will need a design document before coding so we know what we're aiming at. I can lead on that. Fantastic. We can discuss things here. If the discussion becomes to heavy and getting unrelated to mod_perl list, we can move it elsewhere. e.g. [EMAIL PROTECTED] or if you host the project on sourceforge, we can use their list. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: knowledge base - was Re: RFC: mod_perl 2.0 documentation project
On Wed, Aug 08, 2001 at 10:45:43AM +0800, Stas Bekman wrote: On Tue, 7 Aug 2001, Jim Smith wrote: On Tue, Aug 07, 2001 at 10:16:26PM +0800, Stas Bekman wrote: Just some pseudo-random ideation boiling down to let's use mod_perl to buils a knowledge base both to demonstrate it's power and to serve the community. I like the idea!!! If we can come up with a proposal for a generic knowledge base product that would be useful in an IT environment, I can probably devote some of my work to it -- this is something I've been wanting to put together at work for customers and our help desk people but haven't had time yet to get it all together. I'll have more time in September after the students return. go ahead and be the first to propose Jim :) Ok... here are some of my initial thoughts. We need to be able to enter arbitrary documents, so I suggest DocBook as the standard format. This handles articles, books, reference pages, etc., in a well-defined manner. It also allows us to transform to other formats without much of a problem. We can even consider AxKit for at least part of the web interface. We would want to have different sections for documents that are not related. For example, we (here at TAMU) could use a section on Unix, another on Mac, and yet another on Windows systems. Or we could divide it up by services. The different sections would not expect overlap in keyword - content mapping, so we could have an AI::Catagorize object for each section that could provide a default set of keywords. As we entered documents, those objects could learn which keywords were appropriate. We would want to have documents in multiple catagories. This might require the person entering the document enter multiple sets of keywords, one per section. We would need to index on keyword so people could quickly find the documents. Perhaps even a catelogue-style interface for browsing that would be based on keyword categories. This would require some work. (Broad categories are indicated by the presence of certain keywords, or by a weighted average so a document having all but a couple of the appropriate keywords won't be dropped from that category.) Documents shouldn't have to be entered via the web interface, though they could be. We could provide a set of web-page templates for each of the DocBook formats (well, the small ones anyway - don't want to write a book via a web interface). Might want to even integrate with WebDAV and a repository. We probably want to set up a SourceForge project if this is a go. Any ideas on names? Now to see if I can get my boss to support me spending time on such a project :) --jim
Re: RFC: mod_perl 2.0 documentation project
[Barrie, I hope you don't mind that I put it on the list, the more people contribute the better the outcome :)] Hi Stas, sorry it took so long to get back to this :-/. it's not late al all, really ;0) we have years to come to work on this project. Some minor feedback. I could see an additional books, a troubleshooting reference (as opposed to a guide, like part VI). Many service organizations have large manuals that are essentially a compendium of failure modes and instructions for how to troubleshoot each one. Seems like a searchable database of error messages, etc. might be a boon to the community. Given some keywords or a message, you could find (in one query) articles in the db *and* mailing list messages related to them. I could see the usual knowledge base type rank this article. Something like this: http://perl.apache.org/guide/troubleshooting.html ? The problem with DB, is maintence. When it's flat, people read mostly sequentially, point out and fix problems. When it's in the DB, most of the items would hardly come up and it's easier to have stale data in there. Especially when you knowledge base getting big. It's also hard to follow the evolution of the DB, since you don't see the changes like you do with flat files, as they change with CVS commits. I think I need more convincing points to decide to make it as DB. Hmmm, since you've already pointed out that printability is not the primary goal, I wonder if we should just take AxKit and it's nascent CMS and start building a knowledge base? The book format is nice for getting spun up to speed, but the knowledge base interface is what might actually cut down on list traffic. Well, if you don't get to work with XML directly. I sure thing dislike maintaining simple documenents in XML. Since you have to use some web interface to edit the documents, you have no power of editors like vi/emacs, which makes the work much harder. This doesn't mean that you cannot split the flat files into items and have a parallel interface for search. In fact Matt has already done this. Since http://perl.apache.org/guide/troubleshooting.html is all simple items, it's very easy to itemize it. Also don't forget the split version of the guide, used by the search engines: http://perl.apache.org/guide/index.html#search I could even see a search interface on an email address, so when you see a FAQ pop up on-list, a simple forward to [EMAIL PROTECTED] or something would do a search and send you back a message suitable for forwarding to the original poster or something. This would be a very sensitive change. You don't want to AI replies end up on the list, since they won't be correct all the time. But if you only reply to users, humans will still reply, so what's the point :) May be having posts like: WARNING !! !! THIS IS AUTOMATIC GUESS IT CAN BE WRONG ! But definitely an idea to consider and explore. Kinda like the IRC bot purl. Heh, I'd love to play with infobot (==purl) in the real world. I think Kevin said that it's ready for working outside IRC. One of the cool things I thought about is replace Doug's presentation 'command server' protocol with 'infobot' loaded with mod_perl factoids. This will make the presentation even funnier, and we can actually put the bot online for others to re-use! The other book would really be a set of how-tos for getting various systems (templating engines, CMSs) up and running. That's probably a lot like your C.IV, but the howto format has become a meme with a lot of understanding in the community. Sure, there is no limit on how the third book should look. As long as it's manageable and useful for users. The first two books will play it strict. The third one is very flexible. I guess I really see this as more of a mod_perl guide plus knowledge base implementation than a three volume book set, with the pumpkings being series editors for knowledge base articles, and the pumpkins could easily drag in tech editors from the appropriate systems if need be. Yup, exactly. seems very exciting if actually get to implement it. Then the world domation will be finally a next chapter. :) Just some pseudo-random ideation boiling down to let's use mod_perl to buils a knowledge base both to demonstrate it's power and to serve the community. I like the idea!!! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: knowledge base - was Re: RFC: mod_perl 2.0 documentation project
On Tue, 7 Aug 2001, Jim Smith wrote: On Tue, Aug 07, 2001 at 10:16:26PM +0800, Stas Bekman wrote: Just some pseudo-random ideation boiling down to let's use mod_perl to buils a knowledge base both to demonstrate it's power and to serve the community. I like the idea!!! If we can come up with a proposal for a generic knowledge base product that would be useful in an IT environment, I can probably devote some of my work to it -- this is something I've been wanting to put together at work for customers and our help desk people but haven't had time yet to get it all together. I'll have more time in September after the students return. go ahead and be the first to propose Jim :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: RFC: mod_perl 2.0 documentation project
On Tue, 7 Aug 2001, Barrie Slaymaker wrote: On Tue, Aug 07, 2001 at 10:16:26PM +0800, Stas Bekman wrote: [Barrie, I hope you don't mind that I put it on the list, the more people contribute the better the outcome :)] Not at all, I just noticed that others seem to have replied directly and followed suit. yup, whoever wants to dive in, please keep the posts on the list. Don't be shy. Something like this: http://perl.apache.org/guide/troubleshooting.html ? That's what made me think of it. That deals with a lot of the common ones, I was thinking of something more open-ended that would grow to contain more symptoms and (where useful) more details on how to fix things. For instance, including the failures found in a lot of systems would mean covering various tempalting system failures. When creating this page, I've followed a simple rule: when somebody asks a new question and gets an answer, I ignore it, unless the answer is really interesting and covers more than the question's scope. When the same question gets repeated, I add the QA to the troubleshooting chapter. Thus I've avoided having this page bloated. I believe it's probably not a good idea to collect all QAs, because the content will become very hard to maintain and harder to navigate. One of the great things about Perl and mod_perl is the diversity, but it's also daunting to newcomers to identify all the peices and what might be wrong, especially in a troubleshooting situation. Not if they use the search interface, you type in your symptom and you come up with hits. Let's say you see the error: Apache.pm failed to load!, I go to the search input, type in the symptom and the first hit that comes is http://thingy.kcilink.com/modperlguide/troubleshooting/_Apache_pm_failed_to_load_.html May be the problem is in educating users how to use, and not how to store the data. I've never claimed the the current guide is easy to navigate, unless you read it all. But I think the search engine on the split version of the guide does a great job. I use it quite a lot by myself. The problem with DB, is maintence. When it's flat, people read mostly sequentially, point out and fix problems. When it's in the DB, most of the items would hardly come up and it's easier to have stale data in there. Especially when you knowledge base getting big. It's also hard to follow the evolution of the DB, since you don't see the changes like you do with flat files, as they change with CVS commits. New and significantly revised entries could be sent to the list, both to be proofed by area experts and to act as sort of a FAQ a day update to people learning about different sections. Don't want to drive list traffic up, but hey. Hmmm, sonder if a mod_perl FAQ a day list would make sense. Kinda your one-a-day Vitamin MP. This is a hard issue. A. If you create a new list, most of the people won't get on it, because they don't want extra traffic. I assume that this list is not only for sending the QA items, but discussing them as well. B. If you do this on the main list, people will get unsubscribed, because of the heavy traffic. I guess we could have modperl-daily-faq list ala [EMAIL PROTECTED] (which is mainly dead). But this doesn't solve the problem of where the FAQ items are to be discussed. Another problem is how to avoid overlapping with the book/guide like materials. In http://perl.apache.org/guide/troubleshooting.html I've solved this mostly by listing the symptoms only and linking to the portiongs of the guide for the explanations. Having the knowledge base disconnected from the main material will make this duplication removal and maintance overhead very hard. I think I need more convincing points to decide to make it as DB. I think the biggest points are to make it easy to submitting articles and encourage near real-time peer review, along with structured searching. What's the problem to submit articles right now? You want something to be added to the guide, submit to the list, get peer review, get someone to store the cleaned version in the guide, then update the DB. I still prefer to have it flat, while easily convertable to any flexible format imaginable. The idea of throwing many items into DB simple doesn't work, because many records in this database will want to preserve some order between them. For example look at the most disconnected items in the troubleshooting chapter. I've the items sorted by 'configuration', 'build', 'startup', 'run time'... categories, so you can easily narrow your search, by jumping to the right section. I don't say you cannot do this with DB approach, but then it gets complicated as you lose some of the flexibility. In any case, as long as we build the knowledge base in a way that can be easily converted from one format to another without doing any manual adjustments, we can fine tune things as we go. I'd hate to find things not taking off the ground because we cannot agree on
Re: RFC: mod_perl 2.0 documentation project
On Mon, 6 Aug 2001, Jim Smith wrote: On Sat, Aug 04, 2001 at 08:12:25PM +0800, Stas Bekman wrote: This is a proposal for the mod_perl 2.0 documentation project. Sounds good. + each project will have its pumpkin which will make sure that all chapters of the project adher to the same style, avoid duplication, etc. + inside each project, every chapter will have its own pumpkin, whose responsibility will be to maintain the documentation of the given chapter. Other contributors will delegate their patches to the chapter pumpkins and the latter will incorporate the changes into the document. + I'll start as the doc pumkin for the whole project and all sub-projects and will seek to delegate the sub-projects to other folks, as I won't be able to cope with such a big beast anymore. I think we might need a pumpkin that can cross-reference sections. For example, Session management under Mason might go under Mason or Session management. Whichever part doesn't have the text needs a reference to the one that does. (A topic that came up recently on the Mason list.) This is more of a benefit to people that are not familiar with the mod_perl universe and can cut down on fruitless searching. If it isn't cross-referenced, it probably is either not there, or hidden so deeply that it needs to be pointed out by someone. Basically, this would be someone responsible for the `See Also's at the end of each section, article, or what-not. That way, the chapter and project pumpkins can concentrate on their parts of the whole and not feel that they have to constantly be watching everything else. Sure. The intention for the guides to deploy hypertext features, and do lots of internal linking inside every guide and between the guides. This of course makes it hard to read the printed material, but I don't think we can do much about this. Unless we decide to build a fully fledged publishing system, without adding a huge overhead of using TeX or similar things used in real publishing. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RFC: mod_perl 2.0 documentation project
This is a proposal for the mod_perl 2.0 documentation project. The project to consist of 3 parts: mod_perl documentation project: --- A. mod_perl user guide B. mod_perl core developer guide C. mod_perl related guides A is obvious. B is a new thing. If people can easily find they way around mod_perl guts, more patches, rather just bug reports, will be sent, C is an old and a new thing at the same time. The current guide includes a lot of material which is not directly related to mod_perl. I had a hard time deciding what should be included and what not. C is here to make things easier for everbody. It should make the user guide (A) much slimmer and therefore easier to absorb, without losing all the important and interesting information (which will be moved to C and extended there). Here are some other reasons: - mod_perl community includes many great minds whose daily occupation extends far beyond strictly mod_perl programming. So we *can* put these minds to contribute in many other areas, if they are already feeling comfortable contributing to the mod_perl project. This allows us, mod_perl tribe, to learn a lot more without living the mod_perl scope. - some topics, are not directly related to mod_perl, but used by all of us daily, and hence they eventually become accepted for discussion and on-topic. Templating systems and work with databases are two good examples of such a system. Just like with mod_perl, having these threads summarized, can greatly reduce future traffic on the list and have everybody benefit from it. - many mod_perl mailing list users realize that they can get almost *any* question answered on the list, because of the high expertise of the people on the list. We try hard to prevent from mod_perl list becoming a high volume off topic list, but nevertheless these threads happen. At least we want to benefit from them and have the conclusions summarized for others to reuse. Note that I'm in no way try to encourage people to start off-topic threads. - mod_perl community is seeking a world domination. we can easily bring more attention to the mod_perl project by creating documents which can be re-used by the rest of the world, in non-mod_perl related projects. Since we, mod_perl community, host these documents, people get exposed to mod_perl without any special marketing effort and eventually discover its marvels and move to use mod_perl. That's all said, this idea can become true only if people will take over sub-projects, since obviously it cannot be done as a one man job. What we would like to see happen is the following: + we start laying out the infrastructure for the project: directory layout, source pod files conventions, tools for converting the pods into html, ps, pdf, xml, ... + we discuss an initial table of contents for each project (see below). + each project will have its pumpkin which will make sure that all chapters of the project adher to the same style, avoid duplication, etc. + inside each project, every chapter will have its own pumpkin, whose responsibility will be to maintain the documentation of the given chapter. Other contributors will delegate their patches to the chapter pumpkins and the latter will incorporate the changes into the document. + I'll start as the doc pumkin for the whole project and all sub-projects and will seek to delegate the sub-projects to other folks, as I won't be able to cope with such a big beast anymore. + Because of multiplicity it'll be much harder to make sure that there will be not much duplication of materials. We will see how we will handle this problem. + The current guide will eventually get folded into the new plethora of guides. Here is the initial proposal. This is just something I threw together in a few minutes, this will change when we actually start doing things. Your comments are welcome. mod_perl user guide -- Part I: Intro - Introduction into mod_perl - Getting Started Fast Part II: Setup - Installation - Configuration - Server Controlling Part III: Writing Code - Coding - Porting - API Part IV: Databases - Working with DataBases - Sharing Data between threads/processes - IPC? Part V: Performance - Performance Part VI: Solving Problems - Error Handling - Troubleshooting - Getting Helped mod_perl core developer guide --- - mod_perl internals - debugging - submitting patches and mod_perl related guides -- Part I: DataBases - Intro - Choosing the right database for the right task - Database Abstraction Layer - SQL in the Perl way Part II: Templates - Intro - Choosing the right template for the right task - Apache::Template - Part III: Serving Email - Intro - raw SMTP - sendmail - qmail - postfix - ... Part IV: Application Servers/Toolkits/Embedding Perl - Intro - AxKit - Embperl - Apache::ASP - Apache::Pagekit - HTML::Mason
Apache 2.0 / mod_perl 2.0 / Win NT/2000 ? pipe dream ?
Hi all, We currently use (close to) the latest Apache / mod_perl environment on HP/UX. Our holding company is forcing a move to Win2k :/, but they still want to use our mod_perl apps :). I was looking for more information on mod_perl 2.0 today but didn't come up w/much. I have several questions. If you can answer or point to docs, I would be most appreciative. 1) Is moving to mod_perl 2.0 going to require large code changes (even on a *nix system)? 1a) Are there any web sites detailing the types of changes that will be required? 2) I am aware that Apache 2.0 should see a performance increase on NT. Will I be a able to run my current modules in this environment? 2a)Will it be a production level environment? 2b) What will be the performance repercussions (if it will be possible at all)? 3) Is there any commercial company that would provide tech support contracts in this environment (not that I've needed it so far, but the uppers like the safety net)? 4) Is the code base stable enough that I can compile and test this out (I really can't even find a site that deals w/ mod_perl 2 in any detail - probably looking in the wrong places - I would think that perl.apache.org would mention something? - am I blind? ) Thanks for any assistance you can provide. Best Regards, Dave Webmaster MACtac IT Language shapes the way we think, and determines what we can think about. -- B. L. Whorf
Re: Apache 2.0 / mod_perl 2.0 / Win NT/2000 ? pipe dream ?
From: Homsher, Dave V. [EMAIL PROTECTED] Sent: Wednesday, August 01, 2001 12:32 PM Hi all, We currently use (close to) the latest Apache / mod_perl environment on HP/UX. Our holding company is forcing a move to Win2k :/, but they still want to use our mod_perl apps :). I was looking for more information on mod_perl 2.0 today but didn't come up w/much. I have several questions. If you can answer or point to docs, I would be most appreciative. 1) Is moving to mod_perl 2.0 going to require large code changes (even on a *nix system)? 1a) Are there any web sites detailing the types of changes that will be required? Depends on what you are doing, I'll let others comment. 2) I am aware that Apache 2.0 should see a performance increase on NT. Will I be a able to run my current modules in this environment? Depends on how they are written. If you stay within the Apache:: space, yes. The obvious caviats about certain perl functions still apply. 2a)Will it be a production level environment? Yes, but there are still issues (mutiple processes for robustness? no.) 2b) What will be the performance repercussions (if it will be possible at all)? You are hit with extra stats when the server is determining the 'correct canonical filename' since NT is case insensitive. Other than that, this will be a huge boon to mod_perl, since mod_perl on 2.0 supports threads! No more one-worker model :) 3) Is there any commercial company that would provide tech support contracts in this environment (not that I've needed it so far, but the uppers like the safety net)? Covalent (www.covalent.net) where Doug MacEachern and I both work stands strongly behind both Apache 2.0 and mod_perl. I would expect that upper management could feel pretty confident about Covalent support services :) 4) Is the code base stable enough that I can compile and test this out (I really can't even find a site that deals w/ mod_perl 2 in any detail - probably looking in the wrong places - I would think that perl.apache.org would mention something? - am I blind? ) I'm about to try the same thing myself ... I don't know how buildable this is on Windows yet, but I will email the list with whatever I discover. Bill
apachecon/tpc and mod_perl 2.0
So ApacheCon was cool and loaded with mod_perl talks. You gotta read Nat's comments from the last ApacheCon about mod_perl at his journal: http://use.perl.org/journal.pl?op=displayuid=29start=5 Why? Remember last year we have talked about having a dedicated mod_perl conference? And Nat promised us to make everything to have at least a dedicated mod_perl track at the Perl Conference. Nat has kept his promise and thanks to him we have a load of mod_perl talks at the upcoming TPC: We have 6 tutorials (18 hours!) http://conferences.oreillynet.com/cs/os2001/pub/10/mod_perl_tutorials.html We have 16 sessions (10+ hours!) http://conferences.oreillynet.com/cs/os2001/pub/w/os2001/sessions_modperl.html Which gives about 28 hours of pure mod_perl. Nat rules!!! So make sure to be there in crowds, so on the next conference we get this amount of hours and more to cover mod_perl. There are so many interesting talks to go to (not only in the modperl domain), I really don't know what to do. I guess I'll end up jumping from session to session, just to see people talking and then read the handouts :( Oh, if you choose to go with Damian Conway's track, then you don't need to worry. You have him talking for almost all 5 days non-stop :) A good choice :) So to conclude this email, I want to thank Nat for giving us the mod_perl track at the upcoming TPC, and hope that they will keep it in the future. BTW, in Nat's story he incorrectly links to Doug's home page as a source for mod_perl 2.0 cvs snapshots. Instead you want to go here: http://perl.apache.org/from-cvs/modperl-2.0/ (you probably need to subscribe to the dev list ([EMAIL PROTECTED]) if you like playing with fire). (Nat: it's too bad that this link at the top of my post will point to the wrong place, after you add a few more stories, as there is no way to directly link to the entry in your journal.) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
