error
Starting httpd2: Syntax error on line 3 of /etc/httpd/conf.d/75_mod_perl.conf: Cannot load /etc/httpd/2.0/extramodules/mod_perl.so into server: libperl.so: cannot open shared object file: No such file or director Does this mean that libperl is not installed or something else -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: error
I installed apache2 from rpm do I have to reinstall it from source and add mod_perl etc Or can I just reinstall perl and mod_perl Again sorry for these low level questions am a beginner -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 2:57 PM Cc: Steve; [EMAIL PROTECTED] Subject: Re: error You must keep the followups on the list, Steve. > [EMAIL PROTECTED] root]# ldd /etc/httpd/2.0/extramodules/mod_perl.so > libperl.so => not found > libnsl.so.1 => /lib/libnsl.so.1 (0x4003e000) > libdl.so.2 => /lib/libdl.so.2 (0x40052000) > libm.so.6 => /lib/i686/libm.so.6 (0x40056000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40079000) > libutil.so.1 => /lib/libutil.so.1 (0x400a6000) > libpthread.so.0 => /lib/i686/libpthread.so.0 (0x400a9000) > libc.so.6 => /lib/i686/libc.so.6 (0x400f9000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) you must have moved your perl or rebuilt it without shared library after building perl (or may be it's a prepackaged software, in which case you don't have the prerequisite installed). The simplest way is to build mod_perl by yourself. See: http://perl.apache.org/docs/2.0/user/install/install.html __ 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
Re: Mail bounced thru Kazakhstan -- This list only
Jonathan Mangin wrote: Doh. Tell me it's not me and I'll quit uglying up your inbox. --Jon - Original Message - From: "Dooley, Michael" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 09, 2004 5:02 PM Subject: RE: Mail bounced thru Kazakhstan -- This list only its not a problem with the list. it's a problem w/ one of the users on the list. Could possibly be me, I am testing some very agressive spam remedies at this time. Let me know and I'll back off a bit. Steve -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] please test Apache-Test-1.07-dev.tar.gz
Stas Bekman wrote: >A release candidate for Apache-Test-1.07 is available: > >http://apache.org/~stas/Apache-Test-1.07-dev.tar.gz > >Please test and report any failures to this list. > Builds OK & All tests successful on WinXP / MSVC++ 6 / Perl 5.8.2 / Apache 1.3.29 / mod_perl 1.29. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [RELEASE CANDIDATE] please test mod_perl-1.99_12-dev.tar.gz
Stas Bekman wrote: >A release candidate for mod_perl-1.99_12 is available: > >http://apache.org/~stas/mod_perl-1.99_12-dev.tar.gz > >Please test and report any failures to this list. > WinXP / MSVC++ 6 / Perl 5.8.2 (ActivePerl Build 808) / Apache 2.0.48: Builds OK, and the top-level "nmake test" passes all tests successful, but the ModPerl-Registry "nmake test" fails basic.t test 12: C:\Temp\mod_perl-1.99_12-dev\ModPerl-Registry>perl t/TEST -verbose t/basic.t [...] # Running under perl version 5.008002 for MSWin32 # Win32::BuildNumber 808 # Current time local: Fri Dec 19 10:27:28 2003 # Current time GMT: Fri Dec 19 10:27:28 2003 # Using Test.pm version 1.24 [...] # Failed test 12 in basic.t at line 66 fail #3 # testing : ModPerl::RegistryBB mod_cgi-like environment pre-set # expected: it works # received: not ok 12 [...] I'm not sure what the problem is yet. A snapshot of the mp2 CVS that I took on 17 Dec passes all the tests with the same version of Perl and Apache. Here are the entries that have been added to the Change log since I took that snapshot: = Restore a proper behavior of all Registry handlers, but PerlRun, not to reset %INC to forget any .pl files required during the script's execution. [Stas] are now evaluating code into one distinct namespace per container, similar to ModPerl::Registry scripts. [Philippe M. Chiasson] Fix ModPerl::MM::WriteMakefile to use the MODPERL_CCOPTS entry from Apache::BuildConfig, as it contains some flags added by mod_perl, which aren't in perl_ccopts and ap_ccopts. [Stas] Add the implementation of Apache::Connection::local_addr and Apache::Connection::remote_addr to the Apache::compat overridable functions. [Stas] Apache::compat's implementation of APR::URI::unparse, Apache::RequestRec::finfo and Apache::RequestRec::notes is now overridable and not enabled by default. [Stas] Apache::compat no longer enables functions which collide with mp2 API by default. It provides two new functions: override_mp2_api and restore_mp2_api to override and restore the original mp2 API. [Stas] = Hopefully the culprit is there somewhere? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Modperl 2.0 Not finding correct *.conf
Hello, -8<-- Start Bug Report 8<-- 1. Problem Description: It appears, it is still finding a 1.3 Apache install somewhere, and is using this binary, as I have totally renamed /etc/httpd and re-linked this to a directory where the Apache 2.x exists: ie. /usr/local/apache2 Here are the particulars: I am also working on RedHat 9 and have come across the following technologies, am working on: perl 5.8 mysql 4.x DBD-2.9003 DBI-1.38 Apache 2.x apr-0.9.5 apu modperl 2.0 php 4.x java 2.x ssh Apache Source Base = /tmp/cc/httpd-2.0.48 Apache Installed Binary for apxs = /usr/local/apache2/apxs /etc/httpd is a symbolic link to /usr/local/apache2 Contents of script named doit: #!/bin/bash cd /var/modperl-2.0 perl Makefile.PL MP_AP_PREFIX=/tmp/cc/httpd-2.0.48 \ MP_APXS=/usr/local/apache2/bin/apxs MP_INST_APACHE2=1 MP_DEBUG=1 Execution of Script ./doit Produces: [EMAIL PROTECTED] cc]# ./doit Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /tmp/cc/httpd-2.0.48 MP_APXS = /usr/local/apache2/bin/apxs MP_INST_APACHE2 = 1 MP_DEBUG = 1 Configuring Apache/2.0.48 mod_perl/1.99_13-dev Perl/v5.8.0 *** file /etc/httpd/conf.d/*.conf does not exist generating script t/TEST Writing Makefile for Apache::Test generating script t/TEST Writing Makefile for ModPerl::Registry Writing Makefile for APR::Base64 Writing Makefile for APR::Brigade Writing Makefile for APR::Bucket Writing Makefile for APR::Date Writing Makefile for APR::Finfo Writing Makefile for APR::NetLib Writing Makefile for APR::OS Writing Makefile for APR::Pool Writing Makefile for APR::SockAddr Writing Makefile for APR::Socket Writing Makefile for APR::String Writing Makefile for APR::Table Writing Makefile for APR::ThreadMutex Writing Makefile for APR::URI Writing Makefile for APR::UUID Writing Makefile for APR::Util Writing Makefile for APR Writing Makefile for Apache::Access Writing Makefile for Apache::CmdParms Writing Makefile for Apache::Command Writing Makefile for Apache::Connection Writing Makefile for Apache::Directive Writing Makefile for Apache::Filter Writing Makefile for Apache::FilterRec Writing Makefile for Apache::HookRun Writing Makefile for Apache::Log Writing Makefile for Apache::MPM Writing Makefile for Apache::Module Writing Makefile for Apache::Process Writing Makefile for Apache::RequestIO Writing Makefile for Apache::RequestRec Writing Makefile for Apache::RequestUtil Writing Makefile for Apache::Response Writing Makefile for Apache::Server Writing Makefile for Apache::ServerUtil Writing Makefile for Apache::SubProcess Writing Makefile for Apache::SubRequest Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for Apache Writing Makefile for ModPerl::Global Writing Makefile for ModPerl::Util Writing Makefile for ModPerl Writing Makefile for ModPerl::WrapXS Writing Makefile for APR Writing Makefile for APR::Const Writing Makefile for APR::PerlIO Writing Makefile for APR Writing Makefile for Apache::Const Writing Makefile for Apache Writing Makefile for ModPerl::Const Writing Makefile for ModPerl Writing Makefile for ModPerl::XS Writing Makefile for mod_perl *** mod_perl dso library will be built as mod_perl.so *** mod_perl static library will be built as mod_perl.a *** You'll need to add the following to httpd.conf: *** LoadModule perl_module modules/mod_perl.so *** Apache Perl modules will be installed relative to Apache2/ *** Don't forget to: *** - configure 'PerlModule Apache2' in httpd.conf *** - or 'use Apache2 ();' in a startup script *** file /etc/httpd/conf.d/*.conf does not exist [EMAIL PROTECTED] cc]# At least I think I am this far 2. Used Components and their Configuration: *** mod_perl version 1.9913 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS => /usr/local/apache2/bin/apxs MP_AP_PREFIX=> /tmp/cc/httpd-2.0.48 MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /usr/local/apache2/bin/ps -V Server version: Apache/2.0.48 Server built: Dec 4 2003 20:41:23 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/worker" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_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="/usr/local/apache2" -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/ps.conf" *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-l
Re: Modperl 2.0 Not finding correct *.conf
Hello,
make test produced error, looking for
/etc/httpd/*.conf and also let us know that the
version of modperl.c was not compatible.
Was directed to run the following three commands, here
they are with output(Apologize if I have given too
much info, or not followed standard(new on this list):
[EMAIL PROTECTED] modperl-2.0]# t/TEST -conf
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -conf
*** file /etc/httpd/conf.d/*.conf does not exist
*** cleaning out current configuration
*** reconfiguration done
[EMAIL PROTECTED] modperl-2.0]#
[EMAIL PROTECTED] modperl-2.0]# echo edit t/conf/httpd.conf
and remove any references to php
edit t/conf/httpd.conf and remove any references to
php
[EMAIL PROTECTED] modperl-2.0]# vi t/conf/httpd.conf
[EMAIL PROTECTED] modperl-2.0]#
[EMAIL PROTECTED] modperl-2.0]# echo Commented out all PHP
References
Commented out all PHP References
[EMAIL PROTECTED] modperl-2.0]#
[EMAIL PROTECTED] modperl-2.0]# t/TEST
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST
*** root mode: changing the files ownership to
'nobody' (99:99)
*** testing whether 'nobody' is able to -rwx
/var/modperl-2.0/t
/usr/bin/perl -Mlib=/var/modperl-2.0/Apache-Test/lib
-MApache::TestRun -e 'eval {
Apache::TestRun::run_root_fs_test(99, 99,
q[/var/modperl-2.0/t]) }';
*** result: OK
/usr/local/apache2/bin/ps -d /var/modperl-2.0/t -f
/var/modperl-2.0/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
using Apache/2.0.48 (worker MPM)
waiting 180 seconds for server to start: .ps: module
"mod_python.c" is not compatible with this version of
Apache (found 20020628, need 20020903).
Please contact the vendor for the correct version.
!!!
server has died with status 255 (t/logs/error_log
wasn't created, start the server in the debug mode)
[EMAIL PROTECTED] modperl-2.0]#
Thanks kindly for a quick response,
Steve Larson
mailto:[EMAIL PROTECTED]
--- Stas Bekman <[EMAIL PROTECTED]> wrote:
> steve larson wrote:
> > Hello,
> >
> > -8<-- Start Bug Report
> > 8<--
> > 1. Problem Description:
> >
> > It appears, it is still finding a 1.3 Apache
> install
> > somewhere, and is using this binary, as I have
> totally
> > renamed /etc/httpd and re-linked this to a
> directory
> > where the Apache 2.x exists: ie.
> /usr/local/apache2
> > Here are the particulars:
> [...]
> > Contents of script named doit:
> > #!/bin/bash
> > cd /var/modperl-2.0
> > perl Makefile.PL MP_AP_PREFIX=/tmp/cc/httpd-2.0.48
> \
> > MP_APXS=/usr/local/apache2/bin/apxs
> MP_INST_APACHE2=1
> > MP_DEBUG=1
> >
> > Execution of Script ./doit Produces:
> > [EMAIL PROTECTED] cc]# ./doit
> > Reading Makefile.PL args from @ARGV
> >MP_AP_PREFIX = /tmp/cc/httpd-2.0.48
> >MP_APXS = /usr/local/apache2/bin/apxs
> >MP_INST_APACHE2 = 1
> >MP_DEBUG = 1
> > Configuring Apache/2.0.48 mod_perl/1.99_13-dev
> > Perl/v5.8.0
> > *** file /etc/httpd/conf.d/*.conf does not exist
> > generating script t/TEST
> > Writing Makefile for Apache::Test
> > generating script t/TEST
> > Writing Makefile for ModPerl::Registry
>
> [...]
> > Writing Makefile for mod_perl
> > *** mod_perl dso library will be built as
> mod_perl.so
> > *** mod_perl static library will be built as
> > mod_perl.a
> > *** You'll need to add the following to
> httpd.conf:
> > *** LoadModule perl_module modules/mod_perl.so
> >
> > *** Apache Perl modules will be installed relative
> to
> > Apache2/
> > *** Don't forget to:
> > *** - configure 'PerlModule Apache2' in httpd.conf
> > *** - or 'use Apache2 ();' in a startup script
> > *** file /etc/httpd/conf.d/*.conf does not exist
>
> You need to run now:
>
> make && make test && make install
>
> just like with any perl CPAN module.
>
>
__
> 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
>
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Modperl 2.0 Not finding correct *.conf
Hello, Output desired embedded: --- Stas Bekman <[EMAIL PROTECTED]> wrote: > steve larson wrote: > > Hello, > > make test produced error, looking for > > /etc/httpd/*.conf > > it's a warning, not an error. It'd have died if it > was an error. I can see > where the problem is, I'll fix that soonish. It's > unrelated to the problem > preventing you from running the test suite. > > > and also let us know that the > > version of modperl.c was not compatible. > > Was directed to run the following three commands, > here > > they are with output(Apologize if I have given too > > much info, or not followed standard(new on this > list): > > [...] > > > [EMAIL PROTECTED] modperl-2.0]# t/TEST -conf > > *** setting ulimit to allow core files > > ulimit -c unlimited; t/TEST -conf > > *** file /etc/httpd/conf.d/*.conf does not exist > > *** cleaning out current configuration > > *** reconfiguration done > > [EMAIL PROTECTED] modperl-2.0]# > > [EMAIL PROTECTED] modperl-2.0]# echo edit > t/conf/httpd.conf > > and remove any references to php > > edit t/conf/httpd.conf and remove any references > to > > php > > [EMAIL PROTECTED] modperl-2.0]# vi t/conf/httpd.conf > > [EMAIL PROTECTED] modperl-2.0]# > > [EMAIL PROTECTED] modperl-2.0]# echo Commented out all > PHP > > References > > Commented out all PHP References > > [EMAIL PROTECTED] modperl-2.0]# > > [EMAIL PROTECTED] modperl-2.0]# t/TEST > [...] > > waiting 180 seconds for server to start: .ps: > module > > "mod_python.c" is not compatible with this version > of > > Apache (found 20020628, need 20020903). > > Please contact the vendor for the correct version. > > Can you please do: > > % grep mod_python t/conf/httpd.conf > > and post the result here? [EMAIL PROTECTED] modperl-2.0]# grep mod_python t/conf/httpd.conf LoadModule python_module "/usr/local/apache2/modules/mod_python.so" > > BTW, what's 'ps' below: it is an Apache 2.x server, renamed httpd > > > /usr/local/apache2/bin/ps -d /var/modperl-2.0/t > -f > > /var/modperl-2.0/t/conf/httpd.conf -DAPACHE2 > > -DPERL_USEITHREADS > > using Apache/2.0.48 (worker MPM) > > is that how you called your httpd executable? yes > > Where is your apache 1.3 installed? it was in original locations /usr/sbin/httpd /usr/sbin/httpd now shows version [EMAIL PROTECTED] init.d]# /usr/sbin/httpd -v Server version: Apache/2.0.40 Server built: Jul 31 2003 11:36:14 Thanks kindly, Steve Larson [EMAIL PROTECTED] > > __ > 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 > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] free to wrong pool (win32)
Hi Kurt, Kurt George Gjerde wrote: >Hi, > >I'm suddenly getting "Free to wrong pool 12857d8 not 17d8ce0 during >global destruction" when stopping the httpd (after requesting a certain >"script" of mine; I've narrowed the problem down to a module which I've >used for a while without any problems). Anyway, is this something I >should worry about or is this a mp2/perl8/win32 problem that will be >solved in time? > Are you using sections anywhere? There is a (very) long thread (on the dev list) starting here: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106460485716512&w=2 relating to a "Free to wrong pool" error when using sections. The following short httpd.conf file demonstrates the problem in that thread: = LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so ServerName localhost:8529 Listen 8529 ServerRoot C:/Temp/modperl-2.0/t DocumentRoot C:/Temp/modperl-2.0/t/htdocs LogLevel debug Listen 8530 PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib PerlSwitches -IC:/Temp/modperl-2.0/blib/lib PerlSwitches -IC:/Temp/modperl-2.0/blib/arch PerlOptions +Parent 1; = In our case, the server won't even start. In fact, even running apache.exe with the "-t" switch (syntax check) crashes it. Just commenting out the "1;" bit prevents the server from crashing. Your problem is obviously different since you've got your server running, but maybe it's related? - Steve > >The script's running fine with no apparent memory leaks (as far as I can >see) but the OS suggests to send a bug report to Microsoft every time I >stop (or restart) the server (another reason to migrate). > >[Apache/2.0.48 (Win32) mod_perl/1.99_12-dev Perl/v5.8.2] > >thanks, >-Kurt. > > > Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Premature end of script headers
Whenever I try to run a perl script on my server, I keep getting "Internal Server Error." The error logs say "premature end of script headers." My httpd.conf file looks fine, the permissions on the cgi-bin directory and the cgi file itself are fine... everything looks good... so why do I keep getting this error? How do I fix it? ~Steve -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modperl 2.0 Not finding correct *.conf
Hello Stas, am following your advice. I ran into a question that could lead to a longer discussion, just want your opinion which would work best for now, later I can deal with system shortages if produced by this: which is the ideal Apache2, etc. mpm-prefork, mpm-worker, etc. Had started with pre-fork, and built mod-perl produced this output: [EMAIL PROTECTED] modperl]# perl Makefile.PL MP_AP_PREFIX=/usr/local/source/apache2 MP_APXS=/usr/local/source/apache2/support/apxs MP_APR_CONFIG=/usr/local/source/apache2/srclib/apr/apr-config MP_CCOPTS=-DMP_IOBUFSIZE=16384 MP_INST_APACHE2=1 MP_DEBUG=1 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /usr/local/source/apache2 MP_APXS = /usr/local/source/apache2/support/apxs MP_APR_CONFIG = /usr/local/source/apache2/srclib/apr/apr-config MP_CCOPTS = -DMP_IOBUFSIZE=16384 MP_INST_APACHE2 = 1 MP_DEBUG = 1 Configuring Apache/2.0.48 mod_perl/1.99_12 Perl/v5.8.0 !!! Failed to obtain the MPM name. [EMAIL PROTECTED] modperl]# Thanks kindly for your support, Steve Larson [EMAIL PROTECTED] --- Stas Bekman <[EMAIL PROTECTED]> wrote: > steve larson wrote: > > >>>"mod_python.c" is not compatible with this > version > >>of Apache (found 20020628, need 20020903). > >>>Please contact the vendor for the correct > version. > >> > >>Can you please do: > >> > >>% grep mod_python t/conf/httpd.conf > >> > >>and post the result here? > > > > > > [EMAIL PROTECTED] modperl-2.0]# grep mod_python > > t/conf/httpd.conf > > > > LoadModule python_module > > "/usr/local/apache2/modules/mod_python.so" > > So most likely you have your modules in > /usr/local/apache2/modules/ compiled > with an older httpd-2.0 (otherwise why would they > reside in > /usr/local/apache2/modules. > > Suggestion: nuke /usr/local/apache2 (any any other > apache2 dirs), > rebuild/reinstall apache2, then rebuild mod_perl > 2.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 > > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: > http://perl.apache.org/maillist/modperl.html > --- Stas Bekman <[EMAIL PROTECTED]> wrote: > steve larson wrote: > > >>>"mod_python.c" is not compatible with this > version > >>of Apache (found 20020628, need 20020903). > >>>Please contact the vendor for the correct > version. > >> > >>Can you please do: > >> > >>% grep mod_python t/conf/httpd.conf > >> > >>and post the result here? > > > > > > [EMAIL PROTECTED] modperl-2.0]# grep mod_python > > t/conf/httpd.conf > > > > LoadModule python_module > > "/usr/local/apache2/modules/mod_python.so" > > So most likely you have your modules in > /usr/local/apache2/modules/ compiled > with an older httpd-2.0 (otherwise why would they > reside in > /usr/local/apache2/modules. > > Suggestion: nuke /usr/local/apache2 (any any other > apache2 dirs), > rebuild/reinstall apache2, then rebuild mod_perl > 2.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 > > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: > http://perl.apache.org/maillist/modperl.html > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modperl 2.0 Not finding correct *.conf
Hello, I have re-built Apache 2.x with latest, built fine, is not currently running, need to tweak httpd.conf file. Build on myperl creates: [EMAIL PROTECTED] modperl]# cd /usr/local/source/modperl [EMAIL PROTECTED] modperl]# perl Makefile.PL MP_AP_PREFIX=/usr/local/source/apache2 MP_APXS=/usr/local/source/apache2/support/apxs MP_APR_CONFIG=/usr/local/source/apache2/srclib/apr/apr-config MP_CCOPTS=-DMP_IOBUFSIZE=16384 MP_INST_APACHE2=1 MP_DEBUG=1 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /usr/local/source/apache2 MP_APXS = /usr/local/source/apache2/support/apxs MP_APR_CONFIG = /usr/local/source/apache2/srclib/apr/apr-config MP_CCOPTS = -DMP_IOBUFSIZE=16384 MP_INST_APACHE2 = 1 MP_DEBUG = 1 Configuring Apache/2.0.48 mod_perl/1.99_12 Perl/v5.8.0 !!! Failed to obtain the MPM name. Thanks for your support, Steve Larson [EMAIL PROTECTED] --- Stas Bekman <[EMAIL PROTECTED]> wrote: > steve larson wrote: > > Hello Stas, > > am following your advice. I ran into a question > that > > could lead to a longer discussion, just want your > > opinion which would work best for now, later I can > > deal with system shortages if produced by this: > > which is the ideal Apache2, etc. mpm-prefork, > > mpm-worker, etc. > > > > Had started with pre-fork, and built mod-perl > produced > > this output: > > [EMAIL PROTECTED] modperl]# perl Makefile.PL > > MP_AP_PREFIX=/usr/local/source/apache2 > > MP_APXS=/usr/local/source/apache2/support/apxs >^^ > > Configuring Apache/2.0.48 mod_perl/1.99_12 > Perl/v5.8.0 > > !!! Failed to obtain the MPM name. > > You need to install Apache first. If you want to > build against uninstalled > Apache (which I think still works), do not pass > MP_APXS. Once you pass MP_APXS > it'll try to use it to get the information about > Apache, but it doesn't work > until Apache is installed. > > > __ > 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 > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modperl 2.0 Not finding correct *.conf
Hello, Apache has been installed, I hadn't mentioned it before because I used the word "Built". All paths point to appropriate directories for Apache. Thanks for your support, :-) Steve Larson [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modperl 2.0 Not finding correct *.conf
Hello, source of Apache 2 was located here: /usr/local/source/apache2 Apache 2 was installed here: /usr/local/apache2 Thanks for your support, Steve Larson [EMAIL PROTECTED] --- Stas Bekman <[EMAIL PROTECTED]> wrote: > steve larson wrote: > > Hello, > > Apache has been installed, I hadn't mentioned it > > before because I used the word "Built". > > > > All paths point to appropriate directories for > Apache. > > > [EMAIL PROTECTED] modperl]# perl Makefile.PL > > MP_AP_PREFIX=/usr/local/source/apache2 > > MP_APXS=/usr/local/source/apache2/support/apxs > > > MP_APR_CONFIG=/usr/local/source/apache2/srclib/apr/apr-config > > You mean you have installed apache2 into > /usr/local/source/apache2? If not > where did you install it to? > > __ > 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 > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modperl 2.0 Not finding correct *.conf
Hello, I have installed apache, and built modperl, here is output from the make test, please let me know if I can overlook certain errors here or these need to be addressed(I assume). Also, I did not add proxy or some other options, ie. deflate, etc. - perhaps this explains why certain tests were skipped. Thanks for your support, :-) Steve Larson [EMAIL PROTECTED] Output from make test [EMAIL PROTECTED] modperl]# echo Error output from make test [EMAIL PROTECTED] modperl]# make test apr-ext/uuid..Can't load '/usr/local/source/mod_perl-1.99_12/t/../blib/arch/Apache2/auto/APR/APR.so' for module APR: /usr/local/source/mod_perl-1.99_12/t/../blib/arch/Apache2/auto/APR/APR.so: undefined symbol: apr_hook_global_pool at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at apr-ext/uuid.t line 25 Compilation failed in require at apr-ext/uuid.t line 25. apr-ext/uuid..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-3 Failed 3/3 tests, 0.00% okay directive/perlNOK 3# Failed test 3 in directive/perl.t at line 27 directive/perlNOK 7# Failed test 7 in directive/perl.t at line 27 fail #2 directive/perlFAILED tests 3, 7 Failed 2/8 tests, 75.00% okay filter/both_str_req_mix...skipped all skipped: cannot find module 'Compress::Zlib', cannot find module 'deflate' filter/both_str_req_proxy.skipped all skipped: cannot find module 'proxy' modperl/request_rec_tie_api...skipped all skipped: perl 5.008: PerlIO is used instead of TIEd IO modules/apache_status.skipped all skipped: CGI.pm (2.93 or higher) or Apache::Request is needed modules/cgi...skipped all skipped: cannot find module 'CGI' modules/cgi2..skipped all skipped: cannot find module 'CGI' modules/cgipost...skipped all skipped: cannot find module 'CGI' modules/cgipost2..skipped all skipped: cannot find module 'CGI' modules/cgiupload.skipped all skipped: cannot find module 'CGI' modules/cgiupload2skipped all skipped: cannot find module 'CGI' modules/include...skipped all skipped: cannot find module 'CGI' modules/include2..NOK 4# Failed test 4 in modules/include2.t atline 30 fail #2 modules/include2..FAILED test 4 Failed 1/4 tests, 75.00% okay modules/proxy.skipped all skipped: cannot find module 'proxy' perl/hash_attack..skipped all skipped: relevant only for perl 5.8.2 and higher perl/ithreads.skipped all skipped: perl 5.8.1 or higher w/ithreads enabled is required perl/ithreads2skipped all skipped: perl 5.8.1 or higher w/ithreads enabled is required Failed TestStat Wstat Total Fail Failed List of Failed --- apr-ext/uuid.t 255 65280 33 100.00% 1-3 directive/perl.t 82 25.00% 3 7 modules/include2.t41 25.00% 4 15 tests skipped. *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) [EMAIL PROTECTED] modperl]# echo output from perl Version [EMAIL PROTECTED] modperl]# perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi uname='linux str' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -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= useperlio= d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=un uselongdouble= usemymalloc=, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fn
Re: Modperl 2.0 Not finding correct *.conf
Hello,
output desired as well as error_log output.
Thanks for your support, :)
Steve Larson
[EMAIL PROTECTED]
[EMAIL PROTECTED] modperl]#
/usr/local/source/mod_perl-1.99_12/t/../blib/arch/Apache2/auto/APR/APR.so
[EMAIL PROTECTED] modperl]# ldd
/usr/local/source/mod_perl-1.99_12/t/../blib/arch/Apache2/auto/APR/APR.so
librt.so.1 => /lib/tls/librt.so.1 (0x40004000)
libm.so.6 => /lib/tls/libm.so.6 (0x40016000)
libcrypt.so.1 => /lib/libcrypt.so.1
(0x40038000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40065000)
libdl.so.2 => /lib/libdl.so.2 (0x4007a000)
libc.so.6 => /lib/tls/libc.so.6 (0x4200)
libpthread.so.0 => /lib/tls/libpthread.so.0
(0x4007f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x8000)
[EMAIL PROTECTED] modperl]#
[EMAIL PROTECTED] modperl]# t/TEST -verbose directive/perl
modules/include2
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -verbose 'directive/perl'
'modules/include2'
*** root mode: changing the files ownership to
'nobody' (99:99)
*** testing whether 'nobody' is able to -rwx
/usr/local/source/mod_perl-1.99_12/t
/usr/bin/perl
-Mlib=/usr/local/source/mod_perl-1.99_12/Apache-Test/lib
-MApache::TestRun -e 'eval {
Apache::TestRun::run_root_fs_test(99, 99,
q[/usr/local/source/mod_perl-1.99_12/t]) }';
*** result: OK
/usr/local/apache2/httpd/prefork/bin/ps -d
/usr/local/source/mod_perl-1.99_12/t
-f
/usr/local/source/mod_perl-1.99_12/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.48 (prefork MPM)
waiting 120 seconds for server to start: ...[Thu Jan
15 22:36:04 2004] [info] 22 Apache:: modules loaded
[Thu Jan 15 22:36:04 2004] [info] 5 APR:: modules
loaded
[Thu Jan 15 22:36:04 2004] [info] base server + 11
vhosts ready to run tests
..
waiting 120 seconds for server to start: ok (waited 8
secs)
server localhost.localdomain:8529 started
server localhost.localdomain:8530 listening
(TestProtocol::echo_filter)
server localhost.localdomain:8531 listening
(TestProtocol::echo)
server localhost.localdomain:8532 listening
(TestPreConnection::note)
server localhost.localdomain:8533 listening
(TestHooks::stacked_handlers2)
server localhost.localdomain:8534 listening
(TestFilter::both_str_con_add)
server localhost.localdomain:8535 listening
(TestFilter::in_str_msg)
server localhost.localdomain:8536 listening
(TestFilter::in_bbs_msg)
server localhost.localdomain:8537 listening
(TestFilter::in_bbs_inject_header)
server localhost.localdomain:8538 listening
(TestDirective::perlmodule)
server localhost.localdomain:8539 listening
(TestDirective::perlrequire)
server localhost.localdomain:8540 listening
(TestPerl::ithreads)
server localhost.localdomain:8541 listening
(TestDirective::perlloadmodule4)
server localhost.localdomain:8542 listening
(TestDirective::perlloadmodule5)
server localhost.localdomain:8543 listening
(TestDirective::perlloadmodule3)
server localhost.localdomain:8544 listening
(TestDirective::perlloadmodule6)
directive/perl..1..8
# Running under perl version 5.008 for linux
# Current time local: Thu Jan 15 22:36:11 2004
# Current time GMT: Fri Jan 16 03:36:11 2004
# Using Test.pm version 1.23
ok 1
ok 2
not ok 3
# Failed test 3 in directive/perl.t at line 27
ok 4
ok 5
ok 6
not ok 7
# Failed test 7 in directive/perl.t at line 27 fail #2
ok 8
FAILED tests 3, 7
Failed 2/8 tests, 75.00% okay
modules/include21..4
# Running under perl version 5.008 for linux
# Current time local: Thu Jan 15 22:36:14 2004
# Current time GMT: Fri Jan 16 03:36:14 2004
# Using Test.pm version 1.23
ok 1
ok 2
# testing : /Perl-SSI/
# expected: (?-xism:Perl-SSI)
# received: use strict;
#
# #XXX: this test needs to be more robust.
# #various output buffers spread across multiple
prints
# #more mod_include features mixed and checking that
the output
# #is *exactly* what we expected, not just matching a
few patterns.
#
# print "Content-type: text/html\n\n";
#
# my $r = shift;
#
# my $test_string = 'Perl-SSI';
#
# $r->subprocess_env->set(MY_TEST => $test_string);
#
# print <
# Local date is
# Brought to you by
#
#
# EOF
ok 3
# testing : /mod_perl/
# expected: (?-xism:mod_perl)
# received: use strict;
#
# #XXX: this test needs to be more robust.
# #various output buffers spread across multiple
prints
# #more mod_include features mixed and checking that
the output
# #is *exactly* what we expected, not just matching a
few patterns.
#
# print "Content-type: text/html\n\n";
#
# my $r = shift;
#
# my $test_string = 'Perl-SSI';
#
# $r->subprocess_env->set(MY_TEST => $test_string);
#
# print <
# Local date is
# Brought to you by
#
#
# EOF
not ok 4
# Failed test 4 in modules/include2.t at line 30 fail
#2
FAILED test 4
Failed 1/4 tests, 75.00% okay
Failed TestStat Wstat Total Fail Failed List
of Failed
---
Re: Modperl 2.0 Not finding correct *.conf
Hello, here is the requested information. Thanks for the support, :) Steve Larson [EMAIL PROTECTED] -8<-- Start Bug Report 8<-- 1. Problem Description: I can explain the reason I was using the apr-config file, due to the several which exist: [EMAIL PROTECTED] root]# find / -name apr-config /usr/local/bin/apr-config /usr/local/apr/bin/apr-config /usr/local/source/httpd-2.0.48/srclib/apr/apr-config [EMAIL PROTECTED] root]# ls -al /usr/local/bin/apr-config lrwxrwxrwx1 root root 29 Jan 4 11:20 /usr/local/bin/apr-config -> /usr/local/apr/bin/apr-config [EMAIL PROTECTED] root]# [EMAIL PROTECTED] root]# ls -al /usr/local/apr/bin/apr-config -rwxr-xr-x1 root root 9001 Dec 6 20:17 /usr/local/apr/bin/apr-config [EMAIL PROTECTED] root]# ls -al /usr/local/source/httpd-2.0.48/srclib/apr/apr-config -rwxr-xr-x1 root root 9006 Jan 12 15:57 /usr/local/source/httpd-2.0.48/srclib/apr/apr-config [EMAIL PROTECTED] root]# This may have been the mistake on my part using the latest apr-config. 2. Used Components and their Configuration: *** mod_perl version 1.9912 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APR_CONFIG => /usr/local/source/apache2/srclib/apr/apr-config MP_APXS => /usr/local/apache2/httpd/prefork/bin/apxs MP_AP_PREFIX=> /usr/local/source/apache2 MP_CCOPTS => -DMP_IOBUFSIZE=16384 MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /usr/local/apache2/httpd/prefork/bin/ps -V Server version: Apache/2.0.48 Server built: Jan 14 2004 13:14:36 Server's Module Magic Number: 20020903:4 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 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_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="/usr/local/apache2/httpd/prefork" -D SUEXEC_BIN="/usr/local/apache2/httpd/prefork/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/ps.conf" *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi uname='linux str' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -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= useperlio= d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=un uselongdouble= usemymalloc=, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers='' gccversion='3.2.2 200302' intsize=r, longsize=r, ptrsize=5, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long' k', ivsize=4' ivtype='l, nvtype='double' o_nonbl', nvsize=, Off_t='', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc' l', ldflags =' -L/u' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs= libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so',
Includes in mod_perl
Hi ppl, I've started programming with Perl some months ago and I want to switch to mod_perl for my website (my older website is an asp website). I readed the tutorials on perl.apache.org but I am still very confused and don't know how to start my new website with mod_perl. Actually : 1. I have only one website running on my Apache webserver (in /htdocs/) 2. I would like to use a templating system so I could write plain html code and include dynamic content between special tags. 3. I would like my webpages to have the same header and footer. What do you suggest me to do : 1. How to modify httpd.conf so mod_perl would be the handler for my only website (my main problem, actually) 2. Can I have all my webpages have the .pl extension and reside in the same directory (/htdocs/) so I could get rid of a /cgi-bin/ subdirectory? Your ideas and basic explanations of mod_perl will be very appreciated. Thanks in advance, Best regards, Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Forestieres La Tuque, P.Q. Tel.: (819) 676-8100 X2833 [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE : Includes in mod_perl
Here are snippets of my httpd.conf file : - ... LoadModule perl_module modules/mod_perl.so ... DocumentRoot "/usr/local/apache2/htdocs" ... Options Indexes +Includes +ExecCGI AllowOverride None Order allow,deny Allow from all ... AddHandler cgi-script .cgi .pl ... ScriptAlias /cgi-bin/ "/usr/local/apache2/htdocs/cgi-bin/" ... AllowOverride None Options None Order allow,deny Allow from all ... Does that help a bit? Thanks again, Regards, Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Forestières La Tuque, P.Q. Tel.: (819) 676-8100 X2833 [EMAIL PROTECTED] > -Original Message- > From: petersm [mailto:[EMAIL PROTECTED] > Sent: Friday, January 16, 2004 4:20 PM > To: Hemond,Steve; [EMAIL PROTECTED] > Subject: Re: Includes in mod_perl > > > Hemond, Steve <[EMAIL PROTECTED]> wrote > > > Actually : > > 1. I have only one website running on my Apache webserver (in > > /htdocs/) > > Maybe if you show us the relevant portions of your > httpd.conf file we could point you in the right direction > since this is were most of that is set up. > > > 2. I would like to use a templating system so I could > write plain html > > code and include dynamic content between special tags. 3. > I would like > > my webpages to have the same header and footer. > > I really enjoy HTML::Template. I use it for both mod_perl > and plain old cgi scripts and it works wonderfully. I > especially like it since even the custom tags that it uses > to fill in dynamic content look and behave like HTML. > > Michael Peters > Venzia > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modperl 2.0 Not finding correct *.conf
Hello, at this point, I have started from scratch with a new Perl 5.8.2, and then rebuilt the modperl 2.0, with new source, source tree. I may still be missing some parts. Herein contains the error outputs from the make test. If you believe these are OK, then I would go on to the make install step - I hesitate as things do not look proper. Thanks kindly for your support, :-| Steve Larson [EMAIL PROTECTED] -8<-- Start Bug Report 8<-- 1. Problem Description: [DESCRIBE THE PROBLEM HERE] Output from make test follows: apr-ext/perlioskipped all skipped: This test is under construction apr-ext/uuid..Can't load '/usr/local/source/modperl-2.0/t/../blib/arch/Apache2/auto/APR/APR.so' for module APR: /usr/local/source/modperl-2.0/t/../blib/arch/Apache2/auto/APR/APR.so: undefined symbol: apr_hook_global_pool at /usr/local/lib/perl5/5.8.2/i686-linux-thread-multi/DynaLoader.pm line 229. at apr-ext/uuid.t line 25 Compilation failed in require at apr-ext/uuid.t line 25. apr-ext/uuid..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-3 Failed 3/3 tests, 0.00% okay compat/conn_authenskipped all skipped: libwww-perl is not installed error/push_handlers...skipped all skipped: This test is under construction filter/both_str_req_mix...skipped all skipped: cannot find module 'Compress::Zlib', cannot find module 'deflate' filter/both_str_req_proxy.skipped all skipped: cannot find module 'proxy' hooks/authen..skipped all skipped: libwww-perl is not installed hooks/authz...skipped all skipped: libwww-perl is not installed modperl/request_rec_tie_api...skipped all skipped: perl 5.008002: PerlIO is used instead of TIEd IO modules/cgi2..skipped all skipped: libwww-perl is not installed, CGI version 3.01 or higher is required modules/cgipost2..skipped all skipped: CGI version 3.01 or higher is required modules/cgiupload.skipped all skipped: libwww-perl is not installed modules/cgiupload2skipped all skipped: libwww-perl is not installed, CGI version 3.01 or higher is required modules/proxy.skipped all skipped: cannot find module 'proxy' protocol/elizaskipped all skipped: cannot find module 'Chatbot::Eliza' Failed TestStat Wstat Total Fail Failed List of Failed --- apr-ext/uuid.t 255 65280 36 200.00% 1-3 14 tests skipped. *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) 2. Used Components and their Configuration: *** mod_perl version 1.9913 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS => /usr/local/apache2/httpd/prefork/bin/apxs MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /usr/local/apache2/httpd/prefork/bin/ps -V Server version: Apache/2.0.48 Server built: Jan 14 2004 13:14:36 Server's Module Magic Number: 20020903:4 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 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_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="/usr/local/apache2/httpd/prefork" -D SUEXEC_BIN="/usr/local/apache2/httpd/prefork/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/ps.conf" *** /usr/local/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration: Platform: osname=linux, osvers=2.4.20-8, archname=i686-linux-thread-multi uname='linux sparkler 2.4.20-8 #1 thu mar 13 17:18:24 est 2003 i686 athlon i386 gnulinux ' config_args='-de -Dusethreads -des -Accflags=-DPERL_REENTRANT_MAXSIZE=655367 -ACCflags=-DUSE_HASH_SEED_EXPLICIT' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=def
Re: Modperl 2.0 Not finding correct *.conf
Hello, embedded responses. Thanks for your support, :-) Steve Larson [EMAIL PROTECTED] --- Stas Bekman <[EMAIL PROTECTED]> wrote: > steve larson wrote: > > Hello, > > at this point, I have started from scratch with > a > > new > > Perl 5.8.2, and then rebuilt the modperl 2.0, with > new > > source, source tree. > > > > I may still be missing some parts. > > > > Herein contains the error outputs from the make > test. > > > > If you believe these are OK, then I would go on > > to the make install step - I hesitate as things do > not > > look proper. > > The good news is that you can now run 'make > install'. Though first I'd advise > to satisfy the prerequisites, such as LWP and CGI > and run 'make test' again, OK, Point taken, can you point me to the document which outlines addition of LWP, CGI, etc. > because at the moment quite a few tests weren't run. > > The only problem in failing apr-ext/perlio is not a > modperl problem. apr-ext > tests the APR:: perl glue outside modperl, which > most likely you aren't going > to use now. so you can ignore it. > > Though let's try to see why it still fails, after we > have spent so much time > on it and nail it down. Agreed > > > apr-ext/perlioskipped > > all skipped: This test is under > construction > > apr-ext/uuid..Can't load > > > '/usr/local/source/modperl-2.0/t/../blib/arch/Apache2/auto/APR/APR.so' > > for module APR: > > > /usr/local/source/modperl-2.0/t/../blib/arch/Apache2/auto/APR/APR.so: > > undefined symbol: apr_hook_global_pool at > > > /usr/local/lib/perl5/5.8.2/i686-linux-thread-multi/DynaLoader.pm > > line 229. > > at apr-ext/uuid.t line 25 > > Compilation failed in require at apr-ext/uuid.t > line > > 25. > > apr-ext/uuid..dubious > > Test returned status 255 (wstat 65280, > 0xff00) > > DIED. FAILED tests 1-3 > > Failed 3/3 tests, 0.00% okay > > what happens if you rebuild mod_perl as you did now, > but adding: > MP_APR_CONFIG=/usr/local/apache2/httpd/prefork/bin/apr-config > You do have > /usr/local/apache2/httpd/prefork/bin/apr-config, > right? No, it is not there it is located: [EMAIL PROTECTED] root]# find / -name apr-config /usr/local/bin/apr-config is a symbolic link to /usr/local/apr/bin/apr-config [EMAIL PROTECTED] t]# ls -al /usr/local/apr/bin/apr-config -rwxr-xr-x1 root root 9001 Dec 6 20:17 /usr/local/apr/bin/apr-config /usr/local/source/httpd-2.0.48/srclib/apr/apr-config [EMAIL PROTECTED] t]# ls -al /usr/local/source/httpd-2.0.48/srclib/apr/apr-config -rwxr-xr-x1 root root 9006 Jan 12 15:57 /usr/local/source/httpd-2.0.48/srclib/apr/apr-config > > I wan't to see the output of: > > /usr/local/apache2/httpd/prefork/bin/apr-config > --link-ld --libs [EMAIL PROTECTED] modperl]# /usr/local/source/httpd-2.0.48/srclib/apr/apr-config --link-ld --libs -L/usr/local/source/httpd-2.0.48/srclib/apr -lapr-0 -lrt -lm -lcrypt -lnsl -ldl [EMAIL PROTECTED] modperl]# /usr/local/apr/bin/apr-config --link-ld --libs -L/usr/local/apr/lib -lapr-0 -lrt -lm -lcrypt -lnsl -ldl > > Also tell me where your libapr-0.so.0.9.5 or > libapr-0.so is They are located: [EMAIL PROTECTED] t]# find / -name libapr-0.so.0.9.5 /usr/local/source/httpd-2.0.48/srclib/apr/.libs/libapr-0.so.0.9.5 [EMAIL PROTECTED] modperl]# find / -name libapr-0.so /usr/local/source/httpd-2.0.48/srclib/apr/.libs/libapr-0.so > > __ > 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 > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Question about handlers
Hi ppl, I have read the docs on perl.apache.org and I still don't understand certain points. mod_perl seem to encourage handlers for handling dynamic website content. I now know to create an handler to automatically add a header and a footer to any .html called in a certain location. This forces me to go back to httpd.conf and add the handler setup there, and restart Apache so the changes will take effect. What if I need more handlers? What if I need handlers for database transactions, etc? Editing httpd.conf and restarting Apache everytime seems wierd to me. I surely don't understand. Actually, the only thing I need to do is to add a header/footer to my webpages. I plan on adding dynamic content based on a database soon. Couldn't I handle these details in simple .pl files? (Like having a .pm acting as a library to my website, containing a bunch of well defined functions). I browsed the web for some mod_perl example site (with source code so I can understand how the content is handled) but didn't find anything. Maybe if you explain me how YOU wrote your website, that'd help. I really need explanations about handlers too. The more I read the docs, the more I am confused. Thanks for your suggestions and help in advance, Best regards, Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Forestieres La Tuque, P.Q. Tel.: (819) 676-8100 X2833 [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Handlers vs Perl scripts
Hi again!
After taking too much time at debugging my Mason bugs (unsuccessfully) ,
I decided to abandon the idea of embedding perl code in my web pages.
I will setup ONE handler that will only generate a header and a footer
on each webpage. I'm not at ease with the idea of having a bunch of
handlers for every dynamic operation and to restart Apache everytime I
setup a new handler, so I will limit myself to my header/footer handler
and do the rest in perl scripts.
My question is : Coding perl scripts like this :
#!/usr/bin/perl
print (" ...")
etc...
is also taking profit of mod_perl? I mean... is that still a good way to
build mod_perl websites?
Instead of embedding perl code in html files to generate stuff from a
database, I would just have to write an entire perl file that will print
the html code (like the example I've shown above) and do the
manipulations on the database at the same time. I'm just wondering if
this is a good idea, or if I am missing the features of mod_perl at all.
If I go with this idea, is there any documentation that shows how to
handle query strings from a simple perl file?
Another question : I would need a sub to insert stuff in the database,
another to extract stuff, another to show date/time, etc. Should I put
these functions in a simple module that I will include in every perl
script?
Thanks a lot for your help,
Best regards,
Steve Hemond
Programmeur Analyste / Analyst Programmer
Smurfit-Stone, Ressources Forestieres
La Tuque, P.Q.
Tel.: (819) 676-8100 X2833
[EMAIL PROTECTED]
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE : Handlers vs Perl scripts
Could anyone explain me why having perl files like :
printf (" blahblahb");
printf ("My name is %s",$name);
Is a wrong idea? :-)
Steve Hemond
Programmeur Analyste / Analyst Programmer
Smurfit-Stone, Ressources Forestières
La Tuque, P.Q.
Tel.: (819) 676-8100 X2833
[EMAIL PROTECTED]
> -Original Message-
> From: David R. Baird [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 27, 2004 12:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Handlers vs Perl scripts
>
>
> Really, everything you are trying to do is made so much easier in
> Mason. Have you tried the Mason list for help with your bugs?
>
> Embedding html inside perl scripts is not the way to go - it'll
> get very unwieldy very quickly.
>
> If you put most of your functions into modules (eg for db
> access), then you can load the modules into your Mason web pages,
> which minimises the amount of perl code in your html. It also
> makes it much easier to debug - you can load the module into a
> test script and check the return values of each function.
>
> Mason makes handling query strings a breeze too.
>
> d.
>
> On 27 Jan 2004 at 10:54, Hemond, Steve wrote:
>
> > Hi again!
> >
> > After taking too much time at debugging my Mason bugs
> (unsuccessfully)
> > , I decided to abandon the idea of embedding perl code in my web
> > pages.
> >
> > I will setup ONE handler that will only generate a header
> and a footer
> > on each webpage. I'm not at ease with the idea of having a
> bunch of
> > handlers for every dynamic operation and to restart Apache
> everytime I
> > setup a new handler, so I will limit myself to my header/footer
> > handler and do the rest in perl scripts.
> >
> > My question is : Coding perl scripts like this :
> >
> > #!/usr/bin/perl
> >
> > print (" ...")
> > etc...
> >
> > is also taking profit of mod_perl? I mean... is that still
> a good way
> > to build mod_perl websites?
> >
> > Instead of embedding perl code in html files to generate
> stuff from a
> > database, I would just have to write an entire perl file that will
> > print the html code (like the example I've shown above) and do the
> > manipulations on the database at the same time. I'm just
> wondering if
> > this is a good idea, or if I am missing the features of
> mod_perl at
> > all.
> >
> > If I go with this idea, is there any documentation that
> shows how to
> > handle query strings from a simple perl file?
> >
> > Another question : I would need a sub to insert stuff in
> the database,
> > another to extract stuff, another to show date/time, etc.
> Should I put
> > these functions in a simple module that I will include in
> every perl
> > script?
> >
> > Thanks a lot for your help,
> >
> > Best regards,
> >
> > Steve Hemond
> > Programmeur Analyste / Analyst Programmer
> > Smurfit-Stone, Ressources Forestieres
> > La Tuque, P.Q.
> > Tel.: (819) 676-8100 X2833
> > [EMAIL PROTECTED]
> >
> >
> > --
> > Reporting bugs: http://perl.apache.org/bugs/
> > Mail list info: http://perl.apache.org/maillist/modperl.html
> > List etiquette:
> http://perl.apache.org/maillist/email- > etiquette.html
>
>
>
> --
>
> Dr. David R. Baird
> ZeroFive Web
> Design
> [EMAIL PROTECTED]
> http://www.zerofive.co.uk
>
> --
> Reporting bugs: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
> List etiquette: http://perl.apache.org/maillist/email-etiquette.html
>
>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Testing mod_perl
Hi people, I just installed Apache2/mod_perl2 and wants to test it. I don't plan to use any templating system so I will do plain CGI. I, however, would like to take profit of the apache::registry for performance. Here is my conf for my site : SetHandler modperl PerlSendHeader On PerlHandler Apache::Registry Options ExecCGI I restart Apache and there I go : [Tue Feb 03 11:23:46 2004] [error] failed to resolve handler `Apache::Registry' [Tue Feb 03 11:23:46 2004] [error] [client 172.17.2.156] Can't locate object method "boot" via package "mod_perl" at /usr/local/lib/perl5/site_perl/5.8.2/aix/Apache/Constants.pm line 8. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.8.2/aix/Apache.pm line 6. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.8.2/aix/Apache.pm line 6. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.8.2/aix/Apache/Registry.pm line 2. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.8.2/aix/Apache/Registry.pm line 2. Compilation failed in require at (eval 2) line 3. What's wrong? Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Forestieres La Tuque, P.Q. Tel.: (819) 676-8100 X2833 [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Handlers/locations
Hi ppl, I have setup Apache2/mod_perl and started writing perl scripts to generate html code. I have a /wood/ directory with two subdirs : /perl/ and /images/ Actually I have setup httpd.conf this way : SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI In my perl file I have this line : And this line: The problem is it don't go at the right place to find my image and stylesheet. [Tue Feb 03 15:08:58 2004] [error] 51806: ModPerl::Registry: /prog/www/wood/perl/menu.css not found or unable to stat [Tue Feb 03 15:08:58 2004] [error] 41882: ModPerl::Registry: /prog/www/wood/perl/images not found or unable to stat If I put the perl files in the root directory (/wood/) and setup httpd conf this way : SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI I make it look under /images/ but it tries to read the .jpg byte per byte like if it would be a perl file! The best solution for me is to have all perl and html files in the root directory, and have the images under the /images/ subdirectory, and maybe the stylesheets in the /style/ subdirectory. What would be the best httpd.conf configuration to do that? Thanks a lot for your help Best regards, Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Forestieres La Tuque, P.Q. Tel.: (819) 676-8100 X2833 [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE : Handlers/locations
Thanks a lot Michael. Everything works fine now. I won't use any templating system and write plain cgi perl code. Templating systems (Mason, EmbPerl, Asp, Template toolkit, etc) are too much pain to compile on Aix 5.1 running Apache2/mod_perl2. I wasted way TOO MUCH time trying to make Mason work on Aix. Gotta like print statements! Thanks, Steve Hemond Programmeur Analyste / Analyst Programmer Smurfit-Stone, Ressources Forestières La Tuque, P.Q. Tel.: (819) 676-8100 X2833 [EMAIL PROTECTED] > -Original Message- > From: Michael C. Davis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 04, 2004 10:15 AM > To: [EMAIL PROTECTED] > Subject: Re: Handlers/locations > > > I had the same issue when I installd modperl. > > My solution was to put everything Perlish in the "root", > with plain HTML stylesheets and images under it. So it > looked like this: > > /htdocs/myapp <-- executable Perl > /htdocs/myapp/img <-- not executable > /htdocs/myapp/css <-- not executable > htdocs/myapp/html <-- not executable > > Then I used directory to tell Apache that the myapp was > executable for perl but everything below it was not, like this: > > # Serves d:\htdocs\smurfbuster\index.html as > http://localhost/smurfbuster/index.html > Alias /myapp/ "d:/htdocs/myapp/" > > Order allow,deny > Allow from all > SetHandler perl-script > PerlResponseHandler ModPerl::Registry > PerlOptions +ParseHeaders > Options +ExecCGI > > > # keep from trying to interpret as Perl for everything under > myapp # note the /* on end of specified directory ... it's > everything in directories BELOW myapp "d:/htdocs/myapp/*"> SetHandler default-handler > > THe above code is not necessarily complete; it's copied and > pasted from different part of my httpd.conf because I now > use HTML::Mason and my setup has changed, but it > demonstrates the basic idea. > > When I was new to Apache and mod_perl, the Apache doc page > that described how to combined multiple directives really > turned the lightbulb on, and it's probably worth reviewing: > > http://httpd.apache.org/docs-2.0/sections.html#mergin > > And I highly recommend HTML::Mason if you are going to write > more than just a few web pages. > > http://www/masonhq.com > > > At 09:05 AM 2/4/04 -0500, Hemond, Steve wrote: > >Hi ppl, > > > >I have setup Apache2/mod_perl and started writing perl scripts to > >generate html code. > > > >I have a /wood/ directory with two subdirs : /perl/ and /images/ > > > >Actually I have setup httpd.conf this way : > > > > > >SetHandler perl-script > >PerlResponseHandler ModPerl::Registry > >PerlOptions +ParseHeaders > >Options +ExecCGI > > > > > >In my perl file I have this line : > > > > > >And this line: > > > > > >The problem is it don't go at the right place to find my image and > >stylesheet. [Tue Feb 03 15:08:58 2004] [error] 51806: > >ModPerl::Registry: /prog/www/wood/perl/menu.css not found > or unable to > >stat [Tue Feb 03 15:08:58 2004] [error] 41882: ModPerl::Registry: > >/prog/www/wood/perl/images not found or unable to stat > > > >If I put the perl files in the root directory (/wood/) and > setup httpd > >conf this way : > >SetHandler perl-script > >PerlResponseHandler ModPerl::Registry > >PerlOptions +ParseHeaders > >Options +ExecCGI > > > > > >I make it look under /images/ but it tries to read the .jpg > byte per > >byte like if it would be a perl file! > > > >The best solution for me is to have all perl and html files > in the root > >directory, and have the images under the /images/ subdirectory, and > >maybe the stylesheets in the /style/ subdirectory. > > > >What would be the best httpd.conf configuration to do that? > > > >Thanks a lot for your help > > > >Best regards, > > > >Steve Hemond > >Programmeur Analyste / Analyst Programmer > >Smurfit-Stone, Ressources Forestieres > >La Tuque, P.Q. > >Tel.: (819) 676-8100 X2833 > >[EMAIL PROTECTED] > > > > > >-- > >Reporting bugs: http://perl.apache.org/bugs/ > >Mail list info: http://perl.apache.org/maillist/modperl.html > >List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > > > > > > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] please test mod_perl-1.99_13-dev.tar.gz
Randy Kobes wrote:
>All tests successful on my Win32: Apache/2.0.48 and
>perl-5.8.3 (ActivePerl 809).
>
Not quite so for me (WinXP / MSVC6 / 2.0.48 / 5.8.3) -- I have to
increase ThreadsPerChild in the mpm_winnt.c section
(Apache-Test/lib/Apache/TestConfig.pm) to some value higher than 20.
I'm not sure how much higher it needs to be, but 50 works for me.
If I don't do that then the test suite doesn't even get off the ground
-- the server starts up but writes an error to the error_log about
having run out of threads ("Server ran out of threads to serve requests.
Consider raising the ThreadsPerChild setting"), and then just sits there
looking stupid. Nothing else happens.
Having made that change, all is OK.
I've no idea why so many threads are needed. I just retried 1.99_12 and
confirmed my suspicion that 20 threads worked fine then, so the
requirement for extra threads comes from something that has been added
since. Any ideas what to try?
- Steve
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] please test mod_perl-1.99_13-dev.tar.gz
Stas Bekman wrote: >Steve Hay wrote: > > >>I have to >>increase ThreadsPerChild in the mpm_winnt.c section >>(Apache-Test/lib/Apache/TestConfig.pm) to some value higher than 20. >>I'm not sure how much higher it needs to be, but 50 works for me. >> >> > >the worker mpm works just fine with just 2 threads, just like his prefork cousin: > > > StartServers 1 > MaxClients 2 > MinSpareThreads 2 > MaxSpareThreads 2 > ThreadsPerChild 2 > MaxRequestsPerChild 0 > > >that means that those extra threads on win32 are used for something else. >Could you figure out why they are needed and what keeps them busy? Try using >the new Apache::VMonitor. It will show you all the active threads and what >they are doing or done recently. > I've looked at that before and can't use it because it depends on GTop which requires libgtop which we haven't got in Windoze land. > >Nothing special that I can think of has changed since _12, besides having a >bigger test suite. For example this could add to the startup time. A-T pings >the server waiting till it's ready. Perhaps these pings (GET /index.html >HTTP1.1) when the server is not ready, consume threads, get them blocking and >at some point there are no more threads to ping with. If that's the case, it >sounds like a bad bug in Apache to me. > >You could test with ModPerl-Registry's make test - it should start much faster >and you probably won't have any problems with 20 threads. Now add sleep 60 or >so in modperl_extra.pl and see if you run out of threads. > ModPerl-Registry's "nmake test" runs fine with 20 threads (waited 31 sec to start up). I added sleep 60 into modperl_extra_startup.pl and it still runs fine with only 20 threads (waited 151 sec to start up this time). So I don't think it's a problem with ping. I'll try chopping some of the new (post _12) tests out to see if I can get it working again. - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] please test mod_perl-1.99_13-dev.tar.gz
Steve Hay wrote: >I'll try chopping some of the new (post _12) tests out to see if I can >get it working again. > If I remove: t/htdocs/vhost/startup.pl t/response/TestVhost/config.pm t/vhost/config.t then run "t/TEST -conf" and then try "nmake test" again, then it's all OK with 20 threads. Increasing ThreadsPerChild to 50 was overkill, though -- it actually works fine (with the vhost tests back in) with just 21 threads. Looks like the new vhost tests need 1 extra thread. Interestingly, the number of threads required seems to be quite specific. If I have 20 specified instead of the 21 that it needs then I get this in the error_log: Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting If I specify 19 threads then I get that error 2 times; if I specify 18 threads then I get it 3 times; ...if I specify 21-X threads then I get it X times. Without the vhost tests, if I specify 20-X threads then I get the error X times. Is this expected behaviour? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: # of threads needed to run winnt mpm correlates to # of vhosts
Stas Bekman wrote: >Bill Stoddard wrote: > > >>William A. Rowe, Jr. wrote: >> >> >> >>>How interesting! thanks for the discovery... FirstBill actually >>>created the >>>connection threadpool for mpm_winnt, iirc, so i'll punt to him or tackle >>>next week. >>>At 11:50 AM 3/9/2004, Stas Bekman wrote: >>> >>> >>> >>>>Steve Hay wrote: >>>> >>>> >>>> >>>>>Steve Hay wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>I'll try chopping some of the new (post _12) tests out to see if I >>>>>>can get it working again. >>>>>> >>>>>> >>>>>If I remove: >>>>> t/htdocs/vhost/startup.pl >>>>> t/response/TestVhost/config.pm >>>>> t/vhost/config.t >>>>>then run "t/TEST -conf" and then try "nmake test" again, then it's >>>>>all OK with 20 threads. >>>>> >>>>> >>>>Would it make any difference if you remove some other vhost, and not >>>>this specific one? e.g. one of the perlloadmodule\d.pm vhosts? >>>> For the record (although I think we realise by now what the problem is): removing a different vhost & Listen directive (I tried perlloadmodule3) also "fixes it" -- i.e. one less thread is required. >>>> >>>> >>>> >>>> >>>>>Increasing ThreadsPerChild to 50 was overkill, though -- it actually >>>>>works fine (with the vhost tests back in) with just 21 threads. >>>>>Looks like the new vhost tests need 1 extra thread. >>>>> >>>>> >>>>Perfect, Steve. We have 20 vhosts and 1 main server => 21. So I >>>>suppose we need to change A-T to figure out how many vhosts it's >>>>going to run and configure that number of threads plus a few more >>>>(let's say 5-10 more). >>>> >>>>Bill, can you please explain why each vhost requires a thread with >>>>winnt mpm? >>>>Is this documented somewhere? Thanks! >>>> >>>> >>Each vhost does not require a thread. Each Listen directive requires a >>thread to accept connections off the network. We have a bug in the mpm >>that causes the "Consider raising the ThreadsPerChild" messaage to be >>issued in odd conditions as you observe. I;ll work on a fix for that >>problem. >> >> > >But what Steve and Randy report is that the server hangs if you have 21 vhosts >(and 21 Listen directives) but less threads, regardless the message. > FirstBill made two statements there, if I'm reading it correctly - (1) each Listen requires a thread; (2) a bug in the mpm sometimes causes bogus warnings to be issued. We have surely fallen foul of the first statement -- we have 21 Listen directives but only 20 threads, so in our case the warning is not bogus. I assume the server "hangs" when the 21st Listen directive finds that there are no more threads and sits there waiting for one to be made available. (The WaitForSingleObject() call in server/mpm/winnt/child.c's mpm_get_completion_context().) Removing whatever bogus warnings there might be sounds great, but I've never actually seen a bogus warning myself so it wouldn't help us here. The solution is therefore for A::T to get clever and figure out how many *Listen directives* there will be and set ThreadsPerChild to that... - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: # of threads needed to run winnt mpm correlates to # of vhosts
Bill Stoddard wrote: >Just committed a fix (please test) to Apache HTTPD 2.1. Patch is here (it should >apply to 2.0): > >http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/winnt/child.c?r1=1.32&r2=1.33 > > Brilliant! That's fixed it straight away -- the mp2 1.99_13 test suite with all 21 Listen's but only 20 ThreadsPerChild now runs perfectly. (Actually, it works fine with only 1 ThreadsPerChild now!!!) It still says it only started 20 threads, though (in error_log). Is that correct? I thought the plan was to bump ThreadsPerChild up, so I was expecting to see an extra thread started. Or is it that ThreadsPerChild threads are still created initially, and up to num_listeners extra threads can now be created later if required. Perhaps a documentation change would be in order too, to mention the effect that the number of listeners now has on ThreadsPerChild? Thanks, - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: # of threads needed to run winnt mpm correlates to # of vhosts
Bill Stoddard wrote: >Steve Hay wrote: > > > >>Bill Stoddard wrote: >> >> >> >> >>>Just committed a fix (please test) to Apache HTTPD 2.1. Patch is here (it should >>>apply to 2.0): >>> >>>http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/winnt/child.c?r1=1.32&r2=1.33 >>> >>> >>> >>> >>Brilliant! That's fixed it straight away -- the mp2 1.99_13 test suite >>with all 21 Listen's but only 20 ThreadsPerChild now runs perfectly. >> >> >I took a different approach to solving the problem. Rather than artificially bumping >ThreadsperChild, I leave >it at the customer configured value and tune the algorithm that manages the >comunication between the accept >threads and the worker thread pool a bit differently. I believe the change I made is >a bit safer than bumping >threadsperchild. > Is it too late for this to go into 2.0.49? (I realise that it probably is, but I thought I'd ask anyway. No harm in trying ;) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: # of threads needed to run winnt mpm correlates to # of vhosts
Stas Bekman wrote:
>Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>Bill Stoddard wrote:
>>>
>>>
>>>
>>>
>>>>Just committed a fix (please test) to Apache HTTPD 2.1. Patch is here
>>>>(it should apply to 2.0):
>>>>
>>>>http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/winnt/child.c?r1=1.32&r2=1.33
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Brilliant! That's fixed it straight away -- the mp2 1.99_13 test
>>>suite with all 21 Listen's but only 20 ThreadsPerChild now runs
>>>perfectly.
>>>
>>>(Actually, it works fine with only 1 ThreadsPerChild now!!!)
>>>
>>>It still says it only started 20 threads, though (in error_log). Is
>>>that correct? I thought the plan was to bump ThreadsPerChild up, so I
>>>was expecting to see an extra thread started. Or is it that
>>>ThreadsPerChild threads are still created initially, and up to
>>>num_listeners extra threads can now be created later if required.
>>>
>>>Perhaps a documentation change would be in order too, to mention the
>>>effect that the number of listeners now has on ThreadsPerChild?
>>>
>>>
>>Can this entry appear at the end of httpd.conf?
>>
>>
>>ThreadsPerChild 20
>>MaxRequestsPerChild 0
>>
>>
>>if so, this patch should do the right thing. If not, a big rewrite will
>>be required as at the moment we don't know the number of listeners when
>>the top of httpd.conf is written.
>>
>>
>
>Steve, Randy, you haven't confirmed whether you want this patch to be in or
>not. Take your time to respond, of course.
>
Sorry, Stas - in the excitement over Bill's patch to fix Apache I
completely forgot about your fix for mp2 running on unfixed Apache's.
I've tried it out now using 2.0.48 (under which 1.99_13's test suite
would normally "hang" for me) and it successfully bumped up the
ThreadsPerChild setting to 22 and the test suite all ran OK.
Is there any way to inspect what version of Apache we're using and only
increment max_clients by vhost_listeners for version < 2.0.50?
It doesn't hurt to always do the increment, of course, but it might be
useful from the point of view of testing Apache too if it wasn't done
when it didn't need to be.
- Steve
>
>
>
>>Index: lib/Apache/TestConfig.pm
>>===
>>RCS file:
>>/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
>>retrieving revision 1.213
>>diff -u -r1.213 TestConfig.pm
>>--- lib/Apache/TestConfig.pm4 Mar 2004 05:51:31 -1.213
>>+++ lib/Apache/TestConfig.pm10 Mar 2004 18:57:07 -
>>@@ -973,6 +973,13 @@
>> $self->server->version_of(\%servername_config)->(@_);
>> }
>>
>>+my $vhost_listeners = 0;
>>+sub vhost_listeners {
>>+my($self, $increment) = @_;
>>+$vhost_listeners++ if $increment;
>>+$vhost_listeners;
>>+}
>>+
>> sub parse_vhost {
>> my($self, $line) = @_;
>>
>>@@ -1019,6 +1026,8 @@
>> #extra config that should go *outside* the
>> @out_config = ([Listen => $vars->{servername} . ':' . $port]);
>>
>>+$self->vhost_listeners(1);
>>+
>> if ($self->{vhosts}->{$module}->{namebased}) {
>> push @out_config => [NameVirtualHost => "*:$port"];
>> }
>>@@ -1395,6 +1404,20 @@
>>
>> $self->postamble_run($out);
>>
>>+# Apache2 (< 2.0.50) winnt mpm requires at least as many threads
>>+# as the number of listeners, which we don't know until all config
>>+# hooks were called, so only at this point we can write
>>ThreadsPerChild
>>+if ($self->server->{rev} == 2 && $self->{mpm} eq 'winnt') {
>>+my $threads = $self->{vars}->{maxclients} +
>>$self->vhost_listeners();
>>+print $out <>+
>>+ThreadsPerChild $threads
>>+MaxRequestsPerChild 0
>>+
>>+
>>+EOI
>>+}
>>+
>> print $out join "\n", @very_last_postamble;
>>
>> close $in;
>>@@ -1840,10 +1863,7 @@
>> MaxRequestsPerChild 0
>>
>>
>>-
>>-ThreadsPerChild 20
>>-MaxRequestsPerChild 0
>>-
>>+
&g
Re: [RELEASE CANDIDATE] mod_perl-1.99_14 RC1
Randy Kobes wrote: >On Thu, 20 May 2004, Geoffrey Young wrote: > > > >>a release candidate for mod_perl 1.99_14 is now available for testing. >> >> >Hi Geoff, > On Win32 (perl-5.8.3, ActivePerl 809 compatible), with >Apache/2.0.49, there's a problem (often) in starting the >tests, due to ThreadsPerChild being set too low (Steve, >do you still find this?). This diff > >=== >Index: Apache-Test/lib/Apache/TestConfig.pm >=== >RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v >retrieving revision 1.222 >diff -u -r1.222 TestConfig.pm >--- Apache-Test/lib/Apache/TestConfig.pm 16 Apr 2004 20:29:23 - 1.222 >+++ Apache-Test/lib/Apache/TestConfig.pm 20 May 2004 06:11:47 - >@@ -1878,7 +1878,7 @@ > > > >-ThreadsPerChild 20 >+ThreadsPerChild 25 > MaxRequestsPerChild 0 > > >=== >allows the tests to start for me. > Not this one again! We've been here several times before -- see http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108296767420298&w=2. The patch above is fine if you think it is worth applying after all (given that Apache 2.0.50 isn't out yet). > >However, I then find some failures due to a problem we >encountered before (occasionally) - on Win32, when comparing >two file names, sometimes the DOS short path name is >compared to the long path name. This doesn't arise for me >all the time, as it seems to depend on where it's unpacked. >In any case, a solution is to use t_catfile of >Apache::TestUtil, rather than catfile of File::Spec, in a >few places, as well as introduce an analagous t_canonpath - >these two functions do what the File::Spec counterparts do, >but for Win32 they convert the filename to a long path name, >if relevant. > I don't remember seeing that with mp2, but I know I had it once with apreq2. Your patch seems fine anyway, apart from one problem: I have apache\conftree.t failing tests 6-7. Here's the output under -verbose: # expected: C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs # received: "C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs" not ok 6 # expected: C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs # received: "C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs" not ok 7 The original test did have the double-quotes in the "expected" string, so I'll leave you to figure out an obvious fix. The bad news is that on my setup (Apache 2.0.49, Perl 5.8.4) I haven't yet seen the mp2 test suite run properly yet. (The same Apache/Perl combination worked fine with 1.99_13.) When running "nmake test" I usually get t\compat\send_fd.t and t\directive\setupenv.t failing like this: t\compat\send_fdresponse had protocol HTTP/0.9 (headers not sent?) at t\compat\send_fd.t line 15 t\compat\send_fddubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 1-3 Failed 3/3 tests, 0.00% okay t\directive\setupenvresponse had protocol HTTP/0.9 (headers not sent?) at t\directive\setupenv.t line 12 t\directive\setupenvdubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 1-3 Failed 3/3 tests, 0.00% okay but they both pass OK when I run them manually via t/TEST. I then have "nmake test" sometimes failing completely on t\directive\pod (Apache.exe throws up a popup Application Error and crashes). Other times that test runs OK, but then it hangs on t\error\runtime.t. If I kill that test then rest of the tests complete without error. There's nothing useful in the error_log, and I'm shit out of time to look further into it right now. I'll try to find some time whenever I can, but in the meantime, are you able to try with 5.8.4, Randy? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] mod_perl-1.99_14 RC1
Steve Hay wrote: >Your patch seems fine anyway, apart from one problem: I have >apache\conftree.t failing tests 6-7. Here's the output under -verbose: > ># expected: C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs ># received: "C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs" >not ok 6 ># expected: C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs ># received: "C:\apache2\sources\mod_perl-1.99_14-dev\t\htdocs" >not ok 7 > >The original test did have the double-quotes in the "expected" string, >so I'll leave you to figure out an obvious fix. > Well, duh! Sorry -- I somehow misapplied your patch, which does in fact have the double-quotes in it already! Your patch *does* work fine for me exactly as you wrote it. My humble apologies. - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
BEGIN/END block problems with Win32::Shortcut under mp1
(Non-Win32 users: The real issue here is not Win32-specific.)
I'm trying to write an mp1/Apache::Registry script on Win32 that uses
the Win32::Shortcut module, and I find that it works fine under CGI but
not mod_perl.
I think the problem is this:
Win32::Shortcut in an XS module. The XS file has a BOOT: section which
calls a Win32 API function called CoInitialize(). This is called by
"bootstrap Win32::Shortcut;" when the module is require()'d/use()'d.
The PM file has an END block which calls an XS routine which calls
another Win32 API function called CoUninitialize().
Nothing else in this module works unless it is called *between* those
calls to CoInit and CoUninit.
Under CGI, when my script starts running it runs "use Win32::Shortcut;"
which calls CoInit, then it does whatever it has to do, then exits,
causing the END block to be run, which calls CoUninit. The next time
the script is run we just do it all again:
--
CoInit
# do stuff for request 1
CoUninit
--
CoInit
# do stuff for request 2
CoUninit
--
...
However, under Apache::Registry the CoInit call only gets done once
because the module is only loaded once and thereafter gets cached, but
the END block is still run at the end of every script run, so now we have:
--
CoInit
# do stuff for request 1
CoUninit
--
# do stuff for request 2
CoUninit
--
...
You can see why request 2 doesn't work: CoUninit was called at the end
of request 1 and CoInit hasn't been called since.
I tried placing a "use Win32::Shortcut;" line in my mp1 startup.pl
script (and I also tried "PerlModule Win32::Shortcut" in the httpd.conf
file instead, which I believe amounts to the same thing) to see if this
would help, but it doesn't:
As explained in the mod_perl manpage, the END block will now only get
run once (at server shutdown) because it was encountered during server
startup. I thought that this would solve the problem since now we have
one call to CoInit at startup and one call to CoUninit at shutdown and
neither gets called any other time, but I now find that *no* requests to
the script work, not even the first request!
I think the reason is that the parent Apache.exe loaded the module,
doing the CoInit call (and will later run the END block, doing the
CoUninit too), but the child Apache.exe actually serves the request, and
the CoInit/CoUninit calls have to be made from the same process that
wants to be doing stuff in-between, so now the child doesn't work at all
since it never called CoInit to start with.
The only way that I've got this working so far is to simulate what
Apache::StatINC would do if the module was changed between every
request: I've deleted the loading of the module from server startup,
and now have this in my script:
use Win32::Shortcut;
delete $INC{'Win32/Shortcut.pm'};
require 'Win32/Shortcut.pm';
...
The use() line there gets an END block installed to be run at the end of
every script run, while the delete()/require() calls force the bootstrap
code to be re-run at the start of every script run.
This seems to work (so far!), but is there a more elegant way of doing this?
- Steve
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: BEGIN/END block problems with Win32::Shortcut under mp1
Jan Dubois wrote: >On Tue, 21 Sep 2004, Steve Hay wrote: > > >>(Non-Win32 users: The real issue here is not Win32-specific.) >> >> > >As to Win32::Shortcut: you should just delete the END block from the module. >I see that Sarathy already did this over a year for the version that ships >with ActivePerl. He also gave me his mailbox with accumulated libwin32 >patches and asked me to put out another libwin32 release to CPAN. >Unfortunately I haven't found time to get around to it yet. > Oh - I looked on CPAN for a newer libwin32 or Win32::Shortcut (and even tried dada.perl.it), but didn't think of looking in the latest ActivePerl! I'm a little wary of this fix because MSDN docs say "An apartment must call CoUninitialize once for each successful call it has made to CoInitialize" and "CoUninitialize should be called on application shutdown", but it certainly seems to work and is less messy than what I was doing. > >The other issue you are seeing is that CoInitialize() needs to be called >in each *thread* that wants to make COM calls. To do this properly, the >module needs to provide a CLONE method if you are using Perl threads in >5.8.x. > That's not an issue for me with mp1 because it's single-threaded on Win32. I'll have to bear it in mind when moving to mp2, though, 'cos that's multi-threaded on Win32. > >I have no clue how all this relates to MP1; it is just the subject line that >made me take a brief peek at this message. > Thanks for the tip. It's interesting to note that the purveyors of PerlEx watch this list :) ... - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: BEGIN/END block problems with Win32::Shortcut under mp1
Steve Hay wrote: >Jan Dubois wrote: > > >>The other issue you are seeing is that CoInitialize() needs to be called >>in each *thread* that wants to make COM calls. To do this properly, the >>module needs to provide a CLONE method if you are using Perl threads in >>5.8.x. >> >> >> >That's not an issue for me with mp1 because it's single-threaded on >Win32. I'll have to bear it in mind when moving to mp2, though, 'cos >that's multi-threaded on Win32. > Actually, it *is* an issue for me :( mp1 only uses Perl in a single-threaded way on Win32, but the Apache.exe process itself has (by default) 50 threads which take turns to serve requests. So I find (with your fixed version of Win32::Shortcut) that several consecutive requests all work OK, but then sometime later a subsequent request gets served by a different thread and it breaks because the CoInit wasn't done there. Adding a CLONE method to Win32::Shortcut won't help this either because it's Apache threads causing the problem, not Perl threads. So it's back to my nasty %INC hacking now. Using mod_perl handlers is the only other suggestion so far, but it's not so easy in the software concerned for which I have to maintain CGI compatibility. - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
New to modperl
I have been programming Perl for a number of years now, but mainly on a Win32 platform. I recently purchased a hosting package with Perl, Linux, Apache, MySQL, etc, and they say that the servers are configured to run modperl. I took my existing CGI scirpts and uploaded them and set the proper perms to connect to my SQL database. The scripts seem to run atleast 5 times faster, maby just because I'm on Linux now. My question is how do I know if my scripts are running as modperl? Is there some small test script that will tell me? Thank you Steve _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache2/Modperl2 fails to preload Win32::OLE at server startup
Stas Bekman wrote: >Jan, do you have any idea why the CLONE trick doesn't work? CLONE is >running inside the newly-clonned perl, so thread-safety shouldn't get on >the way, no? > Just a guess -- it may be the same problem with CoInitialize() that I experienced not long ago with Win32::Shortcut. (Win32::OLE does call CoInitialize() in various places.) See this thread: http://marc.theaimsgroup.com/?t=10957839322&r=1&w=2 - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Fix perl/ithreads random failures
Gisle Aas wrote:
>I had to do tests with an older version of mod_perl_1.99 that still
>had the perl/ithreads* tests. I see that these tests was removed from
>the distribution in [1], but I think that if you apply the attached
>patch you can start distribution these tests again.
>
>[1]
>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/lib/ModPerl/Manifest.pm?r1=1.9&r2=1.10
>
mp2 is now in svn, not cvs. Check-out the latest svn revision as
described at:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
and you can try that rather than having to go back to an older version.
The test file, of course, is in the dev source, but is currently marked
as under construction:
http://svn.apache.org/repos/asf/perl/modperl/trunk/t/perl/ithreads.t
Anyway, I tried your patch (with the ithreads test re-instated) and
sadly it didn't fix it for me :( The complete diff of changes that I
made to my svn checkout (revision 111269) are at the end of this mail.
The following test sequence still fails every time for me:
perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
on WinXP with Apache 2.0.50 and Perl 5.8.5.
- Steve
Index: t/response/TestPerl/ithreads.pm
===
--- t/response/TestPerl/ithreads.pm (revision 111269)
+++ t/response/TestPerl/ithreads.pm (working copy)
@@ -57,7 +57,10 @@
$counter_shar += $counter_shar for
1..10;
});
$counter_priv += $counter_priv for 1..10;
-$counter_shar += $counter_shar for 1..10;
+{
+ lock $counter_shar;
+ $counter_shar += $counter_shar for 1..10;
+ }
$thr->join;
ok t_cmp($counter_shar, 2**20, "shared counter");
ok t_cmp($counter_priv, 2**10, "private counter");
Index: t/perl/ithreads.t
===
--- t/perl/ithreads.t (revision 111269)
+++ t/perl/ithreads.t (working copy)
@@ -11,10 +11,9 @@
# perl < 5.6.0 fails to compile code with 'shared' attributes, so we
must skip
# it here.
-#unless ($] >= 5.008001 && $Config{useithreads}) {
-#plan tests => 1, need
-#{"perl 5.8.1 or higher w/ithreads enabled is required" => 0};
-#}
-plan tests => 1, under_construction;
+unless ($] >= 5.008001 && $Config{useithreads}) {
+plan tests => 1, need
+{"perl 5.8.1 or higher w/ithreads enabled is required" => 0};
+}
print GET_BODY_ASSERT "/TestPerl__ithreads";
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and
colleagues seasons greetings. We will not be sending corporate greetings
cards this year. Instead, we will be making a donation to charity.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: Fix perl/ithreads random failures
Gisle Aas wrote: >Steve Hay <[EMAIL PROTECTED]> writes: > > > >>Gisle Aas wrote: >> >> >> >>>I had to do tests with an older version of mod_perl_1.99 that still >>>had the perl/ithreads* tests. I see that these tests was removed from >>>the distribution in [1], but I think that if you apply the attached >>>patch you can start distribution these tests again. >>> >>>[1] >>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/lib/ModPerl/Manifest.pm?r1=1.9&r2=1.10 >>> >>> >>> >>mp2 is now in svn, not cvs. >> >> > >Isn't CVS in sync as well? > >I read <http://perl.apache.org/contribute/> and it only mentioned CVS >and had a pointer to the CVS web interface. > > > >> Check-out the latest svn revision as described at: >> >>http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution >> >> > >This one also has pointers to the CVS snapshots and the CVS web >interface so I assume that it is kept in sync. > > Other people can say for sure whether cvs is kept in sync, but my impression was that it was not. I could be wrong. Anyway, svn is definitely the way forward. I know that not all the docs have been updated yet, hence there are various references to cvs around the place still. > > >>and you can try that rather than having to go back to an older version. >> >> > >The patch was reletive to an older version by from glancing at the CVS >head it looked that it would apply there as well. > > Yes, the patch applied to the current svn version. > > >>The test file, of course, is in the dev source, but is currently marked >>as under construction: >> >>http://svn.apache.org/repos/asf/perl/modperl/trunk/t/perl/ithreads.t >> >>Anyway, I tried your patch (with the ithreads test re-instated) and >>sadly it didn't fix it for me :( The complete diff of changes that I >>made to my svn checkout (revision 111269) are at the end of this mail. >> >>The following test sequence still fails every time for me: >> >>perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t >> >>on WinXP with Apache 2.0.50 and Perl 5.8.5. >> >> > >So what is the output when this fails? > >I tested on HP-UX/IA-64 and the fix cured the problem there. The fix >is also obviously correct as both the parent and the child thread >needs to lock for it to take effect. > I can't argue about whether it is correct or not, it's just that it didn't fix the failures that I've been experiencing for some time on WinXP. On WinXP the test sequence that I posted in my last mail causes the Apache.exe process to crash. Nothing is written to the error_log, and only this appears in the console (even with the -verbose option): t\perl\ithreads.request has failed (the response code was: 500) see t/logs/error_log for more details dubious Test returned status 9 (wstat 2304, 0x900) There is no popup application error dialogue box, hence no opportunity to step into the source and even see where it crashed. This has been discussed several times on the dev list (which is probably where we should be now...), most recently here: http://marc.theaimsgroup.com/?t=11014108433&r=1&w=2 Stas can't even reliably reproduce the problem on Linux, so hasn't been able to debug it himself at all. What was the problem that you had on HP/UX? Was it crashing or just failing (as in "not ok")? - Steve Radan Computational Ltd. We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [mp1] 1.29 release candidate #1
Philippe M. Chiasson wrote: The mod_perl 1.29 release candidate #1 has arrived. It can be downloaded here: http://www.apache.org/~gozer/mp1/mod_perl-1.28_01-dev-rc1.tar.gz MD5 : 9f3e81dcdea7cdda3715631c25e446ef SHA1: 1d14efb2ad89750dabcb3780b92992c1b8744551 Passed all tests on WinXP/MSVC++6 with Apache 1.3.28/Perl 5.8.1. Is there any chance of getting a fixed up Apache::Reload module into this? I already have that module in my own Apache/Perl setup, but it never got fixed in the way that was discussed a while ago (to provide an "UndefOnReload" option like Apache::StatINC has), and it was definitely going to be put into mp1 & mp2 with that fix in it as a replacement for Apache::StatINC... There are various threads in which this was all discussed at length, e.g. http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105545899207827&w=2 http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105591352209314&w=2 What's the current situation on all this? - Steve
Re: Switch (module) and mod_perl problem.
Geoffrey Young wrote:
John Day wrote:
In my never ending search for more elegant looking and
self-documenting code I decided to try out the Switch module. In the
following fragment of code:
#!/usr/local/bin/perl
# AppSys: Manage Profile
use strict;
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
use Switch;
my $cgi = CGI->new;
my $control = 'Search';
switch ( $control ) {
case ("Search") { print $cgi->header;
print $cgi->start_html;
print $cgi->p("Search");
print $cgi->end_html;
}
}
produces the following in the Apache error log:
[error] syntax error at /home/appsys/www/modperl/ap03.pl line 12,
near ") {"
syntax error at /home/appsys/www/modperl/ap03.pl line 14, near "}
}"
When run as an Apache::Registry script.
Switch uses source filters, which probably doesn't work well with the
way Registry wraps scripts up into handler() subs.
without getting too far into Filter::Util::Call, Switch.pm, or
Text::Balanced there is probably not much we can do to help.
Indeed. I've tried and failed to get source code filters working under
Apache::Registry in the past, and I tried it again only recently with
the same result -- it doesn't work.
However, it does work fine if you write mod_perl handler()'s yourself.
- Steve
OraTS: Oracle-based Template System - a new web authoring tool
Hi, I have developed a new web authoring tool that enables developers to write web sites in Oracle's PL/SQL programming language (the underlying software however is written in mod_perl). This is the first announcement released to the public. If you work in an Oracle centric shop, you might be interested in this. If you are interested in this project, please join my mailing list on SourceForge. Thanks to Jonathan Swartz for his input of making this an open source project, and the excellent code base of Mason 1.2. Any input is welcome. http://orats.sourceforge.net/ <http://orats.sourceforge.net/> - OraTS: Oracle-based Template System OraTS is a fast-development component-based template system built on Oracle 9i. It is inspired by JSP and mod_perl/Mason <http://www.masonhq.com> . Instead of using Java or Perl, OraTS enables web developers to use Oracle PL/SQL as your web authoring language. If you are a PL/SQL intensive developer, OraTS is for you. Its goal is to simplify the infrastructure complexity and skill set required of the web development in an Oracle centric shop. Once OraTS is set up, all you need to do is to write PL/SQL and HTML code in a local file system. Your web pages will just show up in front of you right away... Important features includes ... * Component-Based * Fast Development * PL/SQL as Web Authoring Language * Superior SQL Performance * Session Support * Robust And Simple This project is not affiliated with Oracle Corporation at all. All the related softwares can be obtained free of charge, except the Oracle 9i Server. Steve Lihn -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::AuthCookie and HTML::Mason
Hi there,
I am using Apache/1.3.22 (Unix) with mod_perl/1.26 and have just installed the
latest Apache::AuthCookie (3.06) and am building a custom AuthCookieHandler
building on an example from the Mason Book.
The Mason login form is being displayed correctly by Apache when accessing the
required resource, but I can't seem to actually authenticate properly. The
initial reason I get back from Apache::AuthCookie via
$r->prev->subprocess_env("AuthCookieReason") is the expected "no_cookie". So,
I then try to log in passing the required credential_ params back to the custom
AuthCookieHandler and get back from Apache::AuthCookie "bad_cookie".
So from the preamble to the newbie question! :
How do I go about getting more information back to my login form from Apache
using mod_perl in my custom AuthCookieHandler as to what the "bad_cookie"
message actually means without trying to decipher much of the magic in
Apache::AuthCookie?
The Apache::AuthCookie code says the following where "bad_cookie" is set :
# There was a session key set, but it's invalid for some reason. So,
# remove it from the client now so when the credential data is posted
# we act just like it's a new session starting.
and the pod says :
# The cookie the user presented is invalid. Typically this means that
the user
# is not allowed access to the given page.
Any help appreciated. I hope the question makes sense.
Thanks,
- Steve
http://www.zepphy.com/
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] mod_perl-2.0.0 RC1
Philippe M. Chiasson wrote: >a long awaited release candidate for mod_perl 2.0.0 is now available for >testing. > >please grab the candidate from: > >http://www.apache.org/~gozer/mp2/mod_perl-2.0.0/mod_perl-2.0.0-RC1.tar.gz > > MD5: d069e5d442ae7d75cd4a366fb65ab125 > SHA1: ad4537a9799a5b812136863f9c95d94c13a52d04 > >and report back successes or failures. > All tests successful on WinXP/VC++ 6.0 using Apache 2.0.50 + Perl 5.8.5. - Steve Radan Computational Ltd. We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
ModPerl Installiation help
I'm running Redhat 8 pretty sure the default Apache installed is 2.0, not infront of my laptop at the moment. Could someone please point me in the direction to where I can get everything I need to get ModPerl running. I have read tons of information but it all seems such a mess! Is installing this as simple as installing a few modules, and adding some lines to my httpd.conf file? or do I need to compile from binary? I have been programming Perl on Windoze for many years now, and now need to switch to Linux. Any help greatly appreciated. Steve .^. /V\ /( )\ ^^_^^
ModPerl Installiation help
I just installed Fedora core 3, everything. The default Perl install is 5.8.5 and not sure about Apache for httpd -v does not display the version. My question is how do I now install modperl and get it working. Do I have to download another version of Perl and Apache to rebuild? I have never used modperl before let alone install it. Could someone please point me in the right direction. I really want to learn this. Thank you Steve
ModPerl Installiation help
I just installed Fedora core 3, everything. The default Perl install is 5.8.5 and not sure about Apache for httpd -v does not display the version. My question is how do I now install modperl and get it working. Do I have to download another version of Perl and Apache to rebuild? I have never used modperl before let alone install it. Could someone please point me in the right direction. I really want to learn this. Thank you Steve
Re: Docs error?
Stas Bekman wrote: >Geoffrey Young wrote: > > >>>Since when unescaped & in the QUERY_STRING part of the URL are not allowed? >>> >>> >>I dunno the specifics, but if you try using the w3c validator you end up >>with something like this >> >> reference not terminated by REFC delimiter >> >> http://example.com/foo.pl?foo=bar®=foobar";>is this valid? >> >> If you meant to include an entity that starts with "&", then you should >> terminate it with ";". Another reason for this error message is that you >> inadvertently created an entity by failing to escape an "&" character just >> before this text. >> >>I swear last time I checked my own html there was a pointer to the >>appropriate rfc, but I guess not. >> >> > >OK, in which case it must be some relatively recent change, since an >unescaped & in the QUERY_STRING was a valid separator. A pointer to the >relevant RFC would be nice so we can add that to the URL that started this >thread. > Here? http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2 Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Stas Bekman wrote: >The uploaded file > > mod_perl-2.0.0-RC6.tar.gz > >has entered CPAN > Almost all OK on Win32 (Apache 2.0.54 and a recent bleadperl). Main tests are all successful, but ModPerl-Registry tests failed 404.t test 1 and redirect.t test 2. The 404.t test gives the following verbose output: t\4041..2 # Running under perl version 5.009003 for MSWin32 # Current time local: Wed May 4 11:19:42 2005 # Current time GMT: Wed May 4 10:19:42 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.23 # Failed test 1 in t\404.t at line 14 # testing : test ErrorDocument # expected: Oops, can't find the requested doc # received: not ok 1 # testing : the script has changed the status to 404 # expected: 404 # received: 404 ok 2 and writes this (only to the error_log: "*** The following error entry is expected and harmless ***". The access_log seems to show a 200/OK rather than a 404: 127.0.0.1 - - [04/May/2005:11:28:35 +0100] "GET /index.html HTTP/1.0" 200 956 127.0.0.1 - - [04/May/2005:11:28:37 +0100] "GET /error_document/cannot_be_found HTTP/1.0" 200 - 127.0.0.1 - - [04/May/2005:11:28:37 +0100] "GET /registry/status_change.pl HTTP/1.0" 404 223 Is that what's expected? The redirect.t test outputs: t\redirect1..4 # Running under perl version 5.009003 for MSWin32 # Current time local: Wed May 4 11:21:31 2005 # Current time GMT: Wed May 4 10:21:31 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.23 # testing : test redirect: existing target # expected: ok C:/apache2/source/mod_perl-2.0.0-RC6/ModPerl-Registry/t/cgi-bin/basic.pl # received: ok C:/apache2/source/mod_perl-2.0.0-RC6/ModPerl-Registry/t/cgi-bin/basic.pl ok 1 # Failed test 2 in t\redirect.t at line 32 # testing : test redirect: non-existing target # expected: 404 # received: 200 not ok 2 # testing : test Registry style redirect: status # expected: 302 # received: 302 ok 3 # testing : test Registry style redirect: cookie # expected: mod_perl=ubercool; path=/ # received: mod_perl=ubercool; path=/ ok 4 and writes the same message as before (only) into the error_log. The access_log again shows a 200/OK rather than a 404 as expected following the 302: 127.0.0.1 - - [04/May/2005:11:32:55 +0100] "GET /index.html HTTP/1.0" 200 956 127.0.0.1 - - [04/May/2005:11:32:57 +0100] "GET /registry/redirect.pl?/registry/basic.pl HTTP/1.0" 302 223 127.0.0.1 - - [04/May/2005:11:32:58 +0100] "GET /registry/basic.pl HTTP/1.0" 200 75 127.0.0.1 - - [04/May/2005:11:32:58 +0100] "HEAD /registry/redirect.pl?/registry/does_not_exists.pl HTTP/1.0" 302 - 127.0.0.1 - - [04/May/2005:11:32:58 +0100] "HEAD /registry/does_not_exists.pl HTTP/1.0" 200 - 127.0.0.1 - - [04/May/2005:11:32:58 +0100] "HEAD /registry/redirect-cookie.pl?/registry/basic.pl HTTP/1.0" 302 - Any ideas? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Stas Bekman wrote:
>Markus Wichitill wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>Almost all OK on Win32 (Apache 2.0.54 and a recent bleadperl). Main
>>>tests are all successful, but ModPerl-Registry tests failed 404.t test
>>>1 and redirect.t test 2.
>>>
>>>
>>Same here (WinXP, 2.0.54, 5.8.6). modperl_slurp_filename doesn't raise a
>>ENOENT exception when it should. The
>>
>>if (!size) {
>>sv_setpvn(sv, "", 0);
>>return newRV_noinc(sv);
>>}
>>
>>part looks fishy to me. size is 0 and therefore we never get to
>>SLURP_SUCCESS("opening"), which should throw the exception.
>>
>>
>
>Hmm, please see the comment:
>
> /* XXX: could have checked whether r->finfo.filehand is valid and
> * save the apr_file_open call, but apache gives us no API to
> * check whether filehand is valid. we can't test whether it's
> * NULL or not, as it may contain garbagea
> */
>
>how can we test if the filehandle is valid then? may be we should skip
>that bit altogether? Steve, does it work if you comment out the whole
>
> if (!size) { ... }
>
>block?
>
No, it doesn't :(
I even did a complete rebuild in case something didn't get relinked
properly after the change, but it still doesn't fix the two test failures.
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Randy Kobes wrote:
>On Thu, 5 May 2005, Markus Wichitill wrote:
>
>
>
>>Steve Hay wrote:
>>
>>
>>>>how can we test if the filehandle is valid then? may be we should skip
>>>>that bit altogether? Steve, does it work if you comment out the whole
>>>>
>>>> if (!size) { ... }
>>>>
>>>>block?
>>>>
>>>>
>>>No, it doesn't :(
>>>
>>>
>>I've removed the size code, too, and the problem is that after the exception
>>is thrown, neither of the tests in RegistryCooker::read_script apply:
>>
>> if (ref $@ eq 'APR::Error') {
>> return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
>> return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
>> # oops
>> }
>>
>>The actual error code returned by apr_file_open is 720002.
>>
>>
>>
>
>Does the following fix this?
>
>
No. I was just in the process of trying the same thing myself, but it
doesn't fix it for me :(
>===
>Index: xs/APR/Status/APR__Status.h
>===
>--- xs/APR/Status/APR__Status.h(revision 168337)
>+++ xs/APR/Status/APR__Status.h(working copy)
>@@ -16,3 +16,5 @@
> #include "apr_errno.h"
>
> #define mpxs_APR__Status_is_EAGAIN APR_STATUS_IS_EAGAIN
>+#define mpxs_APR__Status_is_EACCES APR_STATUS_IS_EACCES
>+#define mpxs_APR__Status_is_ENOENT APR_STATUS_IS_ENOENT
>Index: xs/maps/apr_functions.map
>===
>--- xs/maps/apr_functions.map (revision 168337)
>+++ xs/maps/apr_functions.map (working copy)
>@@ -649,3 +649,5 @@
>
> MODULE=APR::Status PREFIX=mpxs_APR__STATUS_
> int:DEFINE_is_EAGAIN | | apr_status_t:rc
>+ int:DEFINE_is_EACCES | | apr_status_t:rc
>+ int:DEFINE_is_ENOENT | | apr_status_t:rc
>Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
>===
>--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (revision 168337)
>+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (working copy)
>@@ -34,6 +34,7 @@
> use Apache2::Access ();
>
> use APR::Table ();
>+use APR::Status ();
>
> use ModPerl::Util ();
> use ModPerl::Global ();
>@@ -41,7 +42,6 @@
> use File::Spec::Functions ();
> use File::Basename;
>
>-use APR::Const -compile => qw(EACCES ENOENT);
> use Apache2::Const -compile => qw(:common &OPT_EXECCGI);
> use ModPerl::Const -compile => 'EXIT';
>
>@@ -542,8 +542,8 @@
> $self->log_error("$@");
>
> if (ref $@ eq 'APR::Error') {
>-return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
>-return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
>+return Apache2::Const::FORBIDDEN if APR::Status::is_EACCES($@);
>+return Apache2::Const::NOT_FOUND if APR::Status::is_ENOENT($@);
> }
> else {
> return Apache2::Const::SERVER_ERROR;
>
>
>
>
>
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Randy Kobes wrote: >On Thu, 5 May 2005, Steve Hay wrote: > > > >>Randy Kobes wrote: >> >> >> >>>On Thu, 5 May 2005, Markus Wichitill wrote: >>> >>> >[ ... ] > > >>>>The actual error code returned by apr_file_open is 720002. >>>> >>>> >>>Does the following fix this? >>> >>> >>> >>No. I was just in the process of trying the same thing >>myself, but it doesn't fix it for me :( >> >> > >You probably have to 'nmake clean', then rebuild, for these >changes to propagate - does that work? > No :-s Just did a complete rebuild: Extracted RC6 afresh, applied your patch again. Double-checked it applied correctly. Retested. Still get the same two test failures. Now I'm really confused. If I have a chance tomorrow, I'll have a closer look at what the offending $@ is on my system, but I'm off now... Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Markus Wichitill wrote: >Randy Kobes wrote: > > >>>Randy, if you spot locations in docs and tests that do a comparison with >>>these two constants, which we will now have right, please adjust those. >>>Thank you! >>> >>> >>Thanks, Stas. I've done that, but unfortunately, like Steve, >>I'm also finding these 2 tests still have problems :( I'll >>keep looking ... >> >> > >I guess you two didn't remove the "if (!size)" check like I did? > Shit. How dumb am I? You're absolutely right -- you have to remove the size check as well in order for Randy's fix to even be reached! With this change in place too I now have all tests successful :-) Thanks, Markus! - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
[MP2] Test failure in t/apache/content_length_header.t on mod_perl 2.0.0
-8<-- Start Bug Report 8<-- 1. Problem Description: While installing mod_perl 2.0.0, I had some test failures. t/apache/content_length_header..NOK 2# Failed test 2 in t/apache/content_length_header.t at line 50 t/apache/content_length_header..NOK 5# Failed test 5 in t/apache/content_length_header.t at line 71 t/apache/content_length_header..NOK 17# Failed test 17 in t/apache/content_length_header.t at line 71 fail #2 t/apache/content_length_header..FAILED tests 2, 5, 17 Failed 3/27 tests, 88.89% okay Here's the verbose output from the test... [EMAIL PROTECTED]:~/mod_perl-2.0.0$ t/TEST -verbose t/apache/content_length_header.t [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/steve/mod_perl-2.0.0/t/TEST -verbose 't/apache/content_length_header.t' /usr/sbin/apache2 -d /home/steve/mod_perl-2.0.0/t -f /home/steve/mod_perl-2.0.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.0.53 (worker MPM) waiting 300 seconds for server to start: .[Wed May 25 12:29:50 2005] [info] 6 Apache2:: modules loaded [Wed May 25 12:29:50 2005] [info] 0 APR:: modules loaded [Wed May 25 12:29:50 2005] [info] base server + 27 vhosts ready to run tests ... waiting 300 seconds for server to start: ok (waited 46 secs) server localhost.localdomain:8529 started server localhost.localdomain:8530 listening (filter_out_apache) server localhost.localdomain:8531 listening (TestUser::rewrite) server localhost.localdomain:8532 listening (TestVhost::config) server localhost.localdomain:8533 listening (TestVhost::log) server localhost.localdomain:8534 listening (TestModperl::merge) server localhost.localdomain:8535 listening (TestModperl::perl_options) server localhost.localdomain:8536 listening (TestModperl::setupenv) server localhost.localdomain:8537 listening (TestModules::proxy) server localhost.localdomain:8538 listening (TestProtocol::pseudo_http) server localhost.localdomain:8539 listening (TestProtocol::echo_bbs2) server localhost.localdomain:8540 listening (TestProtocol::echo_block) server localhost.localdomain:8541 listening (TestProtocol::echo_timeout) server localhost.localdomain:8542 listening (TestProtocol::echo_filter) server localhost.localdomain:8543 listening (TestProtocol::echo_bbs) server localhost.localdomain:8544 listening (TestProtocol::echo_nonblock) server localhost.localdomain:8545 listening (TestPreConnection::note) server localhost.localdomain:8546 listening (TestHooks::trans) server localhost.localdomain:8547 listening (TestHooks::hookrun) server localhost.localdomain:8548 listening (TestHooks::startup) server localhost.localdomain:8549 listening (TestHooks::stacked_handlers2) server localhost.localdomain:8550 listening (TestHooks::init) server localhost.localdomain:8551 listening (TestFilter::in_bbs_inject_header) server localhost.localdomain:8552 listening (TestFilter::both_str_con_add) server localhost.localdomain:8553 listening (TestFilter::in_bbs_msg) server localhost.localdomain:8554 listening (TestFilter::in_str_msg) server localhost.localdomain:8555 listening (TestDirective::perlmodule) server localhost.localdomain:8556 listening (TestDirective::perlrequire) server localhost.localdomain:8557 listening (TestDirective::perlloadmodule3) server localhost.localdomain:8558 listening (TestDirective::perlloadmodule4) server localhost.localdomain:8559 listening (TestDirective::perlloadmodule5) server localhost.localdomain:8560 listening (TestDirective::perlloadmodule6) server localhost.localdomain:8561 listening (TestHooks::push_handlers_anon) t/apache/content_length_header1..27 # Running under perl version 5.008004 for linux # Current time local: Wed May 25 12:30:38 2005 # Current time GMT: Wed May 25 17:30:38 2005 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.25 # testing : GET /TestApache__content_length_header code # expected: 200 # received: 200 ok 1 # testing : GET /TestApache__content_length_header C-L header # expected: 0 # received: undef not ok 2 # Failed test 2 in t/apache/content_length_header.t at line 50 # testing : GET /TestApache__content_length_header content # expected: # received: ok 3 # testing : GET /TestApache__content_length_header?set_content_length code # expected: 200 # received: 200 ok 4 # testing : GET /TestApache__content_length_header?set_content_length C-L header # expected: 0 # received: 25 not ok 5 # Failed test 5 in t/apache/content_length_header.t at line 71 # testing : GET /TestApache__content_length_header?set_content_length content # expected: # received: ok 6 # testing : GET /TestApache__content_length_header?send_body code # expected: 200 # received: 200 ok 7 # testing : GET /TestApache__content_length_header?send_body C-L header # expected: undef # received: undef ok 8 # testing : GET /TestApache__content_length_header?send_body content # expected: This
Re: [MP2] Test failure in t/apache/content_length_header.t on mod_perl 2.0.0
On Wed, May 25, 2005 at 02:27:39PM -0400, Philip M. Gollucci wrote: > Stas Bekman wrote: > > >Steve Peters wrote: > > > >>-8<-- Start Bug Report 8<-- > >>1. Problem Description: > >> > >>While installing mod_perl 2.0.0, I had some test failures. > >> > >>t/apache/content_length_header..NOK 2# Failed test 2 in > >>t/apache/content_length_header.t at line 50 > >>t/apache/content_length_header..NOK 5# Failed test 5 in > >>t/apache/content_length_header.t at line 71 > >>t/apache/content_length_header..NOK 17# Failed test 17 in > >>t/apache/content_length_header.t at line 71 fail #2 > >>t/apache/content_length_header..FAILED tests 2, 5, 17 > >>Failed 3/27 tests, 88.89% okay > > > >[...] > > > >>Server version: Apache/2.0.53 > > > > > >smells like a fake 2.0.53 (prepackaged 2.0.53 + patches from 2.1.0, > >which is not supported by mp2.0.0) > > > Yes, you do get this error in 2.1.5-dev. > It doesn't happen in 2.0.5(3|4) > Just tried it with a pristine 2.0.54 and all the tests passed. Hateful Ubuntu! I guess I'll open the ticket with them then :) Steve Peters [EMAIL PROTECTED]
Re: [MP2] Test failure in t/apache/content_length_header.t on mod_perl 2.0.0
On Wed, May 25, 2005 at 02:27:39PM -0400, Philip M. Gollucci wrote: > Stas Bekman wrote: > > >Steve Peters wrote: > > > >>-8<-- Start Bug Report 8<-- > >>1. Problem Description: > >> > >>While installing mod_perl 2.0.0, I had some test failures. > >> > >>t/apache/content_length_header..NOK 2# Failed test 2 in > >>t/apache/content_length_header.t at line 50 > >>t/apache/content_length_header..NOK 5# Failed test 5 in > >>t/apache/content_length_header.t at line 71 > >>t/apache/content_length_header..NOK 17# Failed test 17 in > >>t/apache/content_length_header.t at line 71 fail #2 > >>t/apache/content_length_header..FAILED tests 2, 5, 17 > >>Failed 3/27 tests, 88.89% okay > > > >[...] > > > >>Server version: Apache/2.0.53 > > > > > >smells like a fake 2.0.53 (prepackaged 2.0.53 + patches from 2.1.0, > >which is not supported by mp2.0.0) > > > Yes, you do get this error in 2.1.5-dev. > It doesn't happen in 2.0.5(3|4) > > I tried again with a pristine 2.0.54, and all the tests passed. Hateful Ubuntu! A ticket has been opened with them instead. Steve Peters [EMAIL PROTECTED]
Build of mod_perl 2.0.0 fails on bleadperl - no more HvPMROOT()
As of about a week ago, PMROOT was removed from the HV struct and moved off to magic. Unfortunately, mod_perl seems to be using the HvPMROOT() macro to store away the modperl_interp_t pointer in modperl_interp.h. The comments seem to indicate that mod_perl isn't using PMROOT for its intended purpose, but instead as a quick place to store the interp pointer. So, mod_perl is going to need a new place to put the interp pointer. I'm guessing that it could use PMROOT's new place in magic. Code like the following would probably work get the magic. I haven't tested it, but the code for MP_THX_INTERP_SET would look like... #define MP_THX_INTERP_SET(thx, interp) \ # ifndef(HvPMROOT) MAGIC *mg = mg_find((SV*)thx, PERL_MAGIC_symtab); \ mg->mg_obj = (SV*)interp # else Of course, there may be a much better place or way of doing it which I don't know about. I'm just hoping to start some discussion instead of it being a surprise when 5.9.3 is released. Steve Peters [EMAIL PROTECTED]
mod_perl2: cannot load Apache::AuthCookie for Apache 2.0
Title: Message Hello, I am trying to get Apache::AuthCookie to run under Apache 2. I first downloaded and installed httpd-2.0.54, then mod_perl-2.0.0, then Apache-AuthCookie-3.08. I have the following lines in my httpd.conf file: LoadModule perl_module modules/mod_perl.so PerlModule Apache2::compat PerlModule mod_perl2PerlModule Apache::AuthCookie The first error that I got was that it could not find the Apache::Util module. The only place I could find this was in the mod_perl download, and this will only install if it can see the Apache 1.3 source. So I downloaded and compiled apache_1.3.33, then installed mod_perl-1.29. This is the error that I'm getting now. [Thu Jun 09 19:09:37 2005] [error] Can't locate object method "boot" via package "mod_perl" at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Util.pm line 20.\nCompilation failed in require at /usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookie.pm line 9.\nBEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookie.pm line 9.\nCompilation failed in require at (eval 4) line 3.\n How can I get this to work? Thanks, Steve
RE: mod_perl2: cannot load Apache::AuthCookie for Apache 2.0
Thanks, Fred. It worked. -- Steve Duran Web Administrator -Original Message- From: Fred Moyer [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 2:40 PM To: Steve Duran Cc: modperl@perl.apache.org Subject: Re: mod_perl2: cannot load Apache::AuthCookie for Apache 2.0 > PerlModule Apache2::compat > PerlModule mod_perl2 > PerlModule Apache::AuthCookie Use this line instead for use with mod_perl2 - 'PerlModule Apache2::AuthCookie' > > The first error that I got was that it could not find the > Apache::Util module. The only place I could find this was in the > mod_perl download, and this will only install if it can see the Apache > 1.3 source. So I downloaded and compiled apache_1.3.33, then > installed mod_perl-1.29. This is the error that I'm getting now. > > [Thu Jun 09 19:09:37 2005] [error] Can't locate object method "boot" > via package "mod_perl" at > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Util.pm > line 20.\nCompilation failed in require at > /usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookie.pm line 9.\nBEGIN > failed--compilation aborted at > /usr/lib/perl5/site_perl/5.8.0/Apache/AuthCookie.pm line > 9.\nCompilation failed in require at (eval 4) line 3.\n > > How can I get this to work? > > Thanks, > > Steve
RE: install Apache::compat? (Was Can't load perl file)
Try Apache2::compat -Original Message- From: Nick Pietraniec [mailto:[EMAIL PROTECTED] Sent: Monday, June 13, 2005 1:29 PM To: modperl@perl.apache.org Subject: install Apache::compat? (Was Can't load perl file) I think I've found the problem I was having... When I try to add PerlModule Apache2 PerlModule Apache::compat to my http.conf I get "Can't load perl module for Apache2 for server www.blah.com:80 exiting when I comment out the first line I get to my http.conf I get "Can't load perl module for Apache::compat for server www.blah.com:80 exiting Do I need to do something extra to get this compat module installed on my system? Everything I'm seeing it kind of giving it as a given that it's present. I've mentioned it before, but I'm trying to set up apache 2 (2.0.54) on Windows 2000 Server with SSL (from here -- currently working) http://smithii.com/?q=node/view/30 The latest version of ActivePerl (5.8.7.813) and... mod_perl, which I've installed via the "mpinstall" script here.. http://perl.apache.org/docs/2.0/os/win32/install.html#PPM_Packages -Nick On Jun 10, 2005, at 12:38 AM, Tom Schindl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Well without an error message and the at least the lines of code > fail we > cann't be much of help ;-) > > Tom > > Nick Pietraniec schrieb: > | I had something like > | > | use Apache2 > | use Apache2::compat (); > | > | before, but I pasted directly what was in the tutorial (below) > and it > | worked. > | As long as I'm shooting out an email to the list, does anyone know > | offhand exactly what options I need to put in there to run a > script that > | I'm moving from a apache1/mod_perl1 config? That's why I just > had the > | compat() option. I tried running it with the below options > (thinking > | that because compat was included that I'd be ok) but it failed. > | > | I assume that it depends on what I'm doing exactly in the old > script, > | but was wondering if anyone knew of anything special that I > needed to do > | offhand. I haven't done much research yet... > | > | My current .pl file (same as what's given on the net) > | > | use ModPerl::Util (); > | use Apache2::RequestRec (); > | use Apache2::RequestIO (); > | use Apache2::RequestUtil (); > | use Apache2::ServerRec (); > | use Apache2::ServerUtil (); > | use Apache2::Connection (); > | use Apache2::Log (); > | use Apache2::Const -compile => ':common'; > | use APR::Const -compile => ':common'; > | use APR::Table (); > | use Apache2::compat (); > | use ModPerl::Registry (); > | use CGI (); > | 1; > | > | > | On Jun 9, 2005, at 5:57 AM, Robert wrote: > | > |> "Nick Pietraniec" <[EMAIL PROTECTED]> wrote in message > |> news:[EMAIL PROTECTED] > |> > |>> Turns out it was an error in the mod_perl.pl file > |>> > |>> I took "Can't load" to mean "Where's this file?" Where I > should have > |>> taken it as "There's an error in this file" > |>> > |> > |> What was the problem? I have that error as well and I used the > example > |> from > |> the mod_perl site itself. > |> > |> Robert > |> > |> > | > | > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.0 (GNU/Liux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFCqUOFkVPeOFLgZFIRAhbDAJ41zN8Rl6SZHkK0BJyOnwHAnvaNQwCeIpWO > 9Paxzt0Wx7T6tnMlYz967Ho= > =JySO > -END PGP SIGNATURE- >
Apache::VMonitor and Apache::Scoreboard
Apache::VMonitor and Apache::Scoreboard do not want to compile cleanly under mod_perl 2.0.1. I am running: Centos 4.0 (really Redhat Enterprise Linux 4.0) with the following: httpd-2.0.52-9.ent.centos4.1 perl-5.8.5-12.1 mod_perl-2.0.1-1 Just curious if there are plans to port these over or if I can get the same functionality with different packages? Thanks, Steve
RE: Apache::VMonitor and Apache::Scoreboard
Thanks I will check these out! Steve -Original Message- From: Malcolm J Harwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 28, 2005 2:06 PM To: modperl@perl.apache.org Subject: Re: Apache::VMonitor and Apache::Scoreboard On Tuesday 28 June 2005 02:59 pm, Nielsen, Steve wrote: > Apache::VMonitor and Apache::Scoreboard do not want to compile cleanly > under mod_perl 2.0.1. Did you try the release candidates? http://www.liminalflux.net/perl/Apache-Scoreboard-2.08-RC1.tar.gz http://www.liminalflux.net/perl/Apache-VMonitor-2.05-RC1.tar.gz http://www.liminalflux.net/perl/GTop-0.16-RC1.tar.gz > Just curious if there are plans to port these over or if I can get the same > functionality with different packages? They are ported, just not released yet.
RE: Apache::VMonitor and Apache::Scoreboard
I can get all 3 to compile. But a question on scoreboard: I have to explicitly add in the following INC paths to Makefile.PL so it will compile: INC => '-I/usr/include/httpd -I/usr/include/apr-0 Is there a better to do this (without having to apply this change)? Steve -Original Message- From: Malcolm J Harwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 28, 2005 2:06 PM To: modperl@perl.apache.org Subject: Re: Apache::VMonitor and Apache::Scoreboard On Tuesday 28 June 2005 02:59 pm, Nielsen, Steve wrote: > Apache::VMonitor and Apache::Scoreboard do not want to compile cleanly > under mod_perl 2.0.1. Did you try the release candidates? http://www.liminalflux.net/perl/Apache-Scoreboard-2.08-RC1.tar.gz http://www.liminalflux.net/perl/Apache-VMonitor-2.05-RC1.tar.gz http://www.liminalflux.net/perl/GTop-0.16-RC1.tar.gz > Just curious if there are plans to port these over or if I can get the same > functionality with different packages? They are ported, just not released yet.
RE: Apache::VMonitor and Apache::Scoreboard
The mod_perl is use is built from the current fedora core 4 rpm. When I run apxs I get /usr/include/httpd (which is correct). I don't see the call to apxs anywhere (I looked int ModPerl:MM related code and in Scoreboard). Where is it located? Another issue I see if apr (apache runtime) is packaged separately) and resides in /usr/include/apr-0 on my system. Steve -Original Message- From: Malcolm J Harwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 28, 2005 5:25 PM To: modperl@perl.apache.org Cc: Nielsen, Steve Subject: Re: Apache::VMonitor and Apache::Scoreboard On Tuesday 28 June 2005 04:21 pm, Nielsen, Steve wrote: > I can get all 3 to compile. > > But a question on scoreboard: > > I have to explicitly add in the following INC paths to Makefile.PL so it > will compile: > > INC => '-I/usr/include/httpd -I/usr/include/apr-0 > > Is there a better to do this (without having to apply this change)? What does "apxs -q INCLUDEDIR" return? (as that's where it's getting the include path). How did you build your modperl? -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. - Terry Pratchett, alt.fan.pratchett
[MP2] having trouble obtaining $r
Title: Message Sorry, my last email was sent out without a subject. I'm having trouble getting the request object from mod_perl. Here is the original attempt: #use Apache2::RequestUtil;use Apache2::compat;use Apache; my $r = Apache->request(); This generates the following error: Bareword "Apache2::ServerUtil::server_root" not allowed while "strict subs" in use at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Apache2/compat.pm line 346.BEGIN not safe after errors--compilation aborted at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Apache2/compat.pm line 429. --- This is the second attempt: use Apache2::RequestUtil;#use Apache2::compat;#use Apache; my $r = Apache2::RequestUtil->request; This produces the following error: Can't locate object method "request" via package "Apache2::RequestUtil" --- This is the corresponding section of the httpd.conf file. Uncommenting the SetHandler directive causes the browser to display the code of the perl script. LoadModule perl_module modules/mod_perl.so PerlModule Apache2::compat AddHandler cgi-script .cgiAddHandler perl-script .pl Alias /auth/ "/web/ssldocs/foobar/auth/" AllowOverride None Options +ExecCGI #SetHandler perl-script PerlOptions +GlobalRequest Please advise. Thanks, Steve
RE: [MP2] having trouble obtaining $r
This fixed the problems with both Apache2::RequestUtil and Apache2::compat Thanks! - Steve -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 11:01 AM To: [EMAIL PROTECTED] Cc: modperl@perl.apache.org Subject: Re: [MP2] having trouble obtaining $r > use Apache2::RequestUtil; > my $r = Apache2::RequestUtil->request; > > This produces the following error: > > Can't locate object method "request" via package > "Apache2::RequestUtil" [...] > LoadModule perl_module modules/mod_perl.so > > PerlModule Apache2::compat > > AddHandler cgi-script .cgi > AddHandler perl-script .pl > > Alias /auth/ "/web/ssldocs/foobar/auth/" > > > AllowOverride None > Options +ExecCGI > #SetHandler perl-script > PerlOptions +GlobalRequest > and where exactly do you configure, the registry module, Steve? I can't see it in this config. What if you chance that config to: AllowOverride None Options +ExecCGI SetHandler perl-script PerlResponseHandler ModPerl::Registry -- __ 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: is there a templating system that....
Have you tried Text::TagTemplate? -Original Message- From: Jonathan Vanasco [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 12:31 PM To: mod_perl List Subject: is there a templating system that can someone suggest to me a templating system that does not have a mini-language or is 'executed' - or if it is, it is with low overhead -- i don't want to compile more into the mod_perl process than necessary i don't have a need for any of the mini-language features -- i think i mostly need to only do the equivalent of find/replace (ie regex text into a slot) -- i just don't want to write a bunch of code that handles how to escape user-submitted info. I've been thinking of using html::tree for the templates, and putting data in divs that get specifically altered (i think that would probably be a bit faster than using PETAL, which is my 2nd in line option) I was hoping that someone here might be able to point me in another direction.
Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am trying to get SOAP to work under mod_perl. Googling about and
reading what I can find on it, it looks like there are many ways to do
this, but they are all giving me the same (non-working) result.
I have two systems I'm trying to do this on: A Mac with Apache
1.2.33/mod_perl 1.29, and a Soalris 8 box with Apache 1.1.28 and
mod_perl 1.27.
My most recent attempts have been with Apache::SOAP, so I'll use that as
my example:
I have this in my httpd.conf:
SetHandler perl-script
PerlHandler Apache::SOAP
PerlSetVar dispatch_to 'Demo'
Demo.pm is in the @INC path. It contains:
package Demo;
sub hi {
return "hello, world";
}
I call it like this:
use SOAP::Lite +trace => [qw(all)];
my $soap = SOAP::Lite->uri('http:///Demo');
my $proxy = $soap->proxy('http:///steve/rpc/');
my $obj = $proxy->hi();
print $obj->result;
The (rather verbose) output is:
SOAP::Transport::new: ()
SOAP::Serializer::new: ()
SOAP::Deserializer::new: ()
SOAP::Parser::new: ()
SOAP::Lite::new: ()
SOAP::Transport::HTTP::Client::new: ()
SOAP::Lite::call: ()
SOAP::Serializer::envelope: ()
SOAP::Serializer::envelope: hi
SOAP::Data::new: ()
SOAP::Data::new: ()
SOAP::Data::new: ()
SOAP::Data::new: ()
SOAP::Transport::HTTP::Client::send_receive: HTTP::Request=HASH(0x18baed8)
SOAP::Transport::HTTP::Client::send_receive: POST
http://www.cm.aol.com/steve/rpc/ HTTP/1.1
Accept: text/xml
Accept: multipart/*
Content-Length: 448
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.cm.aol.com/Demo#hi";
http://www.w3.org/1999/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/1999/XMLSchema";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>http://www.cm.aol.com/Demo"/>
SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x18c18e4)
SOAP::Transport::HTTP::Client::send_receive: HTTP/0.9 200 (OK) EOF
Client-Date: Thu, 18 Aug 2005 16:22:41 GMT
Client-Peer: 10.178.2.10:80
Client-Response-Num: 1
Can't call method "result" on an undefined value at ./test1.pl line 13.
SOAP::Lite::DESTROY: ()
SOAP::Serializer::DESTROY: ()
SOAP::Data::DESTROY: ()
SOAP::Data::DESTROY: ()
SOAP::Data::DESTROY: ()
SOAP::Data::DESTROY: ()
SOAP::Deserializer::DESTROY: ()
SOAP::Parser::DESTROY: ()
SOAP::Transport::DESTROY: ()
SOAP::Transport::HTTP::Client::DESTROY: ()
The problem is the $obj is always undefined. This happens whether or not
the method I call actually exists, which leads me to believe the Demo.pm
file isn't even being loaded, but I'm not sure of that. It seems like it
SHOULD be loaded...
On the Mac, calling the method "$proxy->hi();" kills the Apache child
process with an error like this in the error_log:
[Thu Aug 18 09:21:40 2005] [notice] child pid 868 exit signal Bus error (10)
I THINK the child process is being killed on the Solaris box too, but
I'm not sure of that. There's nothing in the log about it, but that's a
production box and I'm not free to mess with it too much in my testing.
As I mentioned, I've tried other methods (SOAP::Transport::HTTP::Apache
and Apache::Registry) and I get exactly the same result. I've follwed
examples from "mod_perl Developer's Cookbook", and "Programming Web
Services with Perl" as well as from perl.apache.org and
guilde.soaplite.com. It's only the mod_perl examples I can't get to
work. I'm using these scripts (Demo.pm and others) fine with CGI SOAP.
I'm thinking something is misconfigured in mod_perl, but darned if I can
figure out what.
Can anyone point out what I'm missing? Or at least point out a different
FM to R?
Thanks
- --
Steve Baker
kiku wa ittoki no haji
kikanu wa matsudai no haji
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDBLn1z179gX3oLkwRAlUAAJ0ZIYhjR3dz2Ig9bybU2o/1qgRNuwCdGqzu
TXhPGhCA8H/rQn63ijW9FVI=
=KGiM
-END PGP SIGNATURE-
Re: Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | On Thu, 2005-08-18 at 09:40 -0700, Steve Baker wrote: | |>I have two systems I'm trying to do this on: A Mac with Apache |>1.2.33/mod_perl 1.29, and a Soalris 8 box with Apache 1.1.28 and |>mod_perl 1.27. | | | One thing that might help is to use the most recent apache and mod_perl | versions (in the 1.x series) on both. It just doesn't help to use | versions with known bugs and security problems. Those versions of | apache are positively antique. I apologize -- that was a massive typo on my part. The versions of apache I am using are 1.3.33 (mac) and 1.3.28 (solaris). So believe I have the latest 1.x Apache/mod_perl on one box, and a set not too much older on the other. Thanks - -- Steve Baker AOL Configuration Management kiku wa ittoki no haji kikanu wa matsudai no haji -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBL/tz179gX3oLkwRAt8hAJ0bWsI35Ou2zZ8OZpb+1WNR42LBXgCdHpdC xkmdLHDmYRzZfW+1iNe9UOs= =gih8 -END PGP SIGNATURE-
Re: Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | On Thu, 18 Aug 2005, Steve Baker wrote: | |> -BEGIN PGP SIGNED MESSAGE- |> Hash: SHA1 |> |> I am trying to get SOAP to work under mod_perl. Googling about and |> reading what I can find on it, it looks like there are many ways to do |> this, but they are all giving me the same (non-working) result. |> |> I have two systems I'm trying to do this on: A Mac with Apache |> 1.2.33/mod_perl 1.29, and a Soalris 8 box with Apache 1.1.28 and |> mod_perl 1.27. |> |> My most recent attempts have been with Apache::SOAP, so I'll use that as |> my example: |> |> I have this in my httpd.conf: |> |> |> SetHandler perl-script |> PerlHandler Apache::SOAP |> PerlSetVar dispatch_to 'Demo' |> |> |> Demo.pm is in the @INC path. | | [ ... ] | If you change the directive specifying dispatch_to to |PerlSetVar dispatch_to "/dir/containing/Demo, Demo" | does that work? | Nope, I get exactly the same error. Thanks - -- Steve Baker AOL Configuration Management kiku wa ittoki no haji kikanu wa matsudai no haji -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBMVfz179gX3oLkwRArSCAJ9TIPHTZ03mqoaaOgaLLwij4EWe4gCeOFgj 6eR2UMxck4s7zwvIpo5m80Q= =cAWZ -END PGP SIGNATURE-
Re: Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
|>I call it like this:
|>
|> use SOAP::Lite +trace => [qw(all)];
|>
|> my $soap = SOAP::Lite->uri('http:///Demo');
|> my $proxy = $soap->proxy('http:///steve/rpc/');
|> my $obj = $proxy->hi();
|> print $obj->result;
|
|
| try
|
| my $soap = SOAP::Lite
| ->uri('http:///Demo')
| ->proxy('http:///steve/rpc/')
| ->on_fault(sub { my ($soap, $res) = @_;
| die ref $res ?
| $res->faultdetail :
| $soap->transport->status, "\n"
|});
|
| that should help you with tracing errors. also, it's been a while since
| I've played around with SOAP::Lite, but IIRC unless you used +autodispatch
| your call ought to look like
|
| my $obj = $soap->call('hi');
| print $obj->result;
Neither change had any effect. The output is exactly the same; no
additional output from the fault handler. This is my client now:
use SOAP::Lite +trace => [qw(all)];
my $soap = SOAP::Lite->uri('http:///Demo')
~->proxy('http:///steve/rpc/')->on_fault(
~sub {
~my ($soap, $res) = @_;
~die ref $res ? $res->faultdetail : $soap->transport->status, "\n";
~}
~);
my $obj = $soap->call('hi');
print $obj->result;
~From the output, it looks like the call is being made, and it is
succeeding:
SOAP::Transport::HTTP::Client::send_receive: POST
http://www.cm.aol.com/steve/rpc/ HTTP/1.1
Accept: text/xml
Accept: multipart/*
Content-Length: 449
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.cm.aol.com/Demo6#hi";
http://www.w3.org/1999/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/1999/XMLSchema";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>http://www.cm.aol.com/Demo6"/>
SOAP::Transport::HTTP::Client::send_receive: HTTP::Response=HASH(0x19076e8)
SOAP::Transport::HTTP::Client::send_receive: HTTP/0.9 200 (OK) EOF
Client-Date: Thu, 18 Aug 2005 17:39:21 GMT
Client-Peer: 10.178.2.10:80
Client-Response-Num: 1
On the other hand, I get similar results with known bad input (calling a
method which doesn't exist, putting a non-existent module name in the
uri, etc) so I'm pretty sure the module is never really loaded.
Thanks
- --
Steve Baker
AOL Configuration Management
kiku wa ittoki no haji
kikanu wa matsudai no haji
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDBMw0z179gX3oLkwRAjuzAKCd/K90YHax+55W4m3Kd3gkitraHgCfabAc
trN0eXt2JuZn8PXnpeaGycI=
=ceYT
-END PGP SIGNATURE-
Re: Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
| On Thu, 18 Aug 2005, Steve Baker wrote:
|
| [ ... ]
|
|> This is my client now:
|>
|> use SOAP::Lite +trace => [qw(all)];
|>
|> my $soap = SOAP::Lite->uri('http:///Demo')
|> ~->proxy('http:///steve/rpc/')->on_fault(
|> ~sub {
|> ~my ($soap, $res) = @_;
|> ~die ref $res ? $res->faultdetail : $soap->transport->status,
|> "\n";
|> ~}
|> ~);
|> my $obj = $soap->call('hi');
|> print $obj->result;
|>
|> ~From the output, it looks like the call is being made, and it is
|> succeeding:
|
| [ ... ]
|
|> On the other hand, I get similar results with known bad input (calling a
|> method which doesn't exist, putting a non-existent module name in the
|> uri, etc) so I'm pretty sure the module is never really loaded.
|
|
| Does adding a
|PerlModule Demo
| to httpd.conf, before the soap location, do anthing different?
|
No, no change at all. :-(
Thanks
- --
Steve Baker
AOL Configuration Management
kiku wa ittoki no haji
kikanu wa matsudai no haji
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDBfraz179gX3oLkwRAvd7AJ4v03quwV8dNe9Gv0Yd2AAE/2ZrywCeNmeF
EQdPdbD/jDG1MUcRzaOrAmw=
=+Uyf
-END PGP SIGNATURE-
Re: Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've continued to work on this, but have been unable to progress past
this point. mod_perl seems to work just fine on both systems, except
when it comes to SOAP, in which case I'm getting exactly the same errors
on both systems. I must be doing SOMETHING wrong, but danged if I can
spot it. While I'm familiar with Perl, I am less familiar with SOAP and
mod_perl. I've doublechecked the httpd.conf entries and I believe they
are correct. The Demo.pm file is too simple to have an error (famous
last words), so now I've concerntrating on the client code, which is the
part I understand the least.
In particular, I'm confused about the value passed to uri(). I'm using
"http:///Demo", where Demo is the name of the module I want
to call, and Demo.pm is in the PATH. That, and "http://localhost/Demo";
both work in my CGI-based SOAP experiments, but neither works with
mod_perl. Is this an area where mod_perl and CGI differ?
Thanks for any clues anyone can provide.
Steve
Steve Baker wrote:
| I am trying to get SOAP to work under mod_perl. Googling about and
| reading what I can find on it, it looks like there are many ways to do
| this, but they are all giving me the same (non-working) result.
|
| I have two systems I'm trying to do this on: A Mac with Apache
| 1.3.33/mod_perl 1.29, and a Soalris 8 box with Apache 1.3.28 and
| mod_perl 1.27.
|
| My most recent attempts have been with Apache::SOAP, so I'll use that as
| my example:
|
| I have this in my httpd.conf:
|
|
| SetHandler perl-script
| PerlHandler Apache::SOAP
| PerlSetVar dispatch_to 'Demo'
|
|
| Demo.pm is in the @INC path. It contains:
|
| package Demo;
|
| sub hi {
| return "hello, world";
| }
|
|
| I call it like this:
|
| use SOAP::Lite +trace => [qw(all)];
|
| my $soap = SOAP::Lite->uri('http:///Demo');
| my $proxy = $soap->proxy('http:///steve/rpc/');
| my $obj = $proxy->hi();
| print $obj->result;
|
| The (rather verbose) output is:
|
| SOAP::Transport::new: ()
| SOAP::Serializer::new: ()
| SOAP::Deserializer::new: ()
| SOAP::Parser::new: ()
| SOAP::Lite::new: ()
| SOAP::Transport::HTTP::Client::new: ()
| SOAP::Lite::call: ()
| SOAP::Serializer::envelope: ()
| SOAP::Serializer::envelope: hi
| SOAP::Data::new: ()
| SOAP::Data::new: ()
| SOAP::Data::new: ()
| SOAP::Data::new: ()
| SOAP::Transport::HTTP::Client::send_receive: HTTP::Request=HASH(0x18baed8)
| SOAP::Transport::HTTP::Client::send_receive: POST
| http://www.cm.aol.com/steve/rpc/ HTTP/1.1
| Accept: text/xml
| Accept: multipart/*
| Content-Length: 448
| Content-Type: text/xml; charset=utf-8
| SOAPAction: "http://www.cm.aol.com/Demo#hi";
|
| http://www.w3.org/1999/XMLSchema-instance";
| xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
| xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
| xmlns:xsd="http://www.w3.org/1999/XMLSchema";
|
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>http://www.cm.aol.com/Demo"/>
|
| SOAP::Transport::HTTP::Client::send_receive:
HTTP::Response=HASH(0x18c18e4)
| SOAP::Transport::HTTP::Client::send_receive: HTTP/0.9 200 (OK) EOF
| Client-Date: Thu, 18 Aug 2005 16:22:41 GMT
| Client-Peer: 10.178.2.10:80
| Client-Response-Num: 1
|
| Can't call method "result" on an undefined value at ./test1.pl line 13.
| SOAP::Lite::DESTROY: ()
| SOAP::Serializer::DESTROY: ()
| SOAP::Data::DESTROY: ()
| SOAP::Data::DESTROY: ()
| SOAP::Data::DESTROY: ()
| SOAP::Data::DESTROY: ()
| SOAP::Deserializer::DESTROY: ()
| SOAP::Parser::DESTROY: ()
| SOAP::Transport::DESTROY: ()
| SOAP::Transport::HTTP::Client::DESTROY: ()
|
|
| The problem is the $obj is always undefined. This happens whether or not
| the method I call actually exists, which leads me to believe the Demo.pm
| file isn't even being loaded, but I'm not sure of that. It seems like it
| SHOULD be loaded...
|
| On the Mac, calling the method "$proxy->hi();" kills the Apache child
| process with an error like this in the error_log:
|
| [Thu Aug 18 09:21:40 2005] [notice] child pid 868 exit signal Bus error
| (10)
|
| I THINK the child process is being killed on the Solaris box too, but
| I'm not sure of that. There's nothing in the log about it, but that's a
| production box and I'm not free to mess with it too much in my testing.
|
| As I mentioned, I've tried other methods (SOAP::Transport::HTTP::Apache
| and Apache::Registry) and I get exactly the same result. I've follwed
| examples from "mod_perl Developer's Cookbook", and "Programming Web
| Services with Perl" as well as from perl.apache.org and
| guilde.soaplite.com. It's only the mod_perl examples I can't get to
| work. I'
Re: Can't get SOAP to work under mod_perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | As Perrin mentioned, this may not be a problem with mod_perl | specifically, so it may be worth asking on the soap-lite | mailing list. Just to verify this, I've placed at | http://people.apache.org/~randyk/ | a file, bug-reporting-skeleton-mp1.tar.gz, which can be | used to test your mod_perl SOAP installation. To use it: | perl Makefile.PL | make | make test | If the tests pass, can you see differences between the | modules and/or configuration used here and the one you | have? If the tests don't pass, is there anything useful | in the error log? Or does | perl t/TEST -v | provide any clues? | It doesn't appear I can run this. It uses ModPerl::MM, which appears to be part of mod_perl 2, but as I mentioned, I'm using 1.29. I thought I'd start with the modperl list, since this all works under CGI, and I assumed the problem would be something I have misconfigured in mod_perl or something I have to do differently with mod_perl. I'll go pester the SOAP people now. :-) Thanks for the help everyone! - -- Steve Baker AOL Configuration Management kiku wa ittoki no haji kikanu wa matsudai no haji -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDCyGiz179gX3oLkwRAjnFAJ9inRKDWODvRNKyjEdrCWVTL8h+RgCfeTMl fv+tH8uELViePDPqhxsD2Yo= =T/Yn -END PGP SIGNATURE-
Re: [RELEASE CANDIDATE] mod_perl-2.0.2 RC2
Philip M. Gollucci wrote: A release candidate for mod_perl 2.0.2 is now available for testing. All tests OK now on WinXP/VC6 with perl-5.8.7 and apache-2.0.54. (And I still have the Apache 1 installed in C:\apache which broke things for me when testing RC1.) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
[mp2] Env Variable / Oracle config problem
Title: Message
Hello,
I'm trying to
get a basic web app running under mod_perl2, using an Oracle database
connection. After I define the environment variables listed below, the
test script works fine from the command line, but fails with the following error
when I try to run it via the web server. If I do not define the
environment variables, I get the same error on the command line as I do from the
web server.
I have tried
different ways of defining the enviroment variables for the script, but nothing
seems to work.
This is the
error that I get from the web server (Apache 2)
[Fri Nov 18 14:15:54 2005] [error] Can't load
'/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: libclntsh.so.9.0: cannot open shared object file: No
such file or directory at
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230. at
/web/cgi-bin/test/test.pl line 6Compilation failed in require at
/web/cgi-bin/test/test.pl line 6.BEGIN failed--compilation aborted at
/web/cgi-bin/test/test.pl line 6.
This is and
excerpt from httpd.conf:
SetEnv ORACLE_HOME /u01/app/oracle/product/9.2.0.4SetEnv
ORACLE_USERID foo/[EMAIL PROTECTED]SetEnv
ASSUME_KERNEL 2.4.19SetEnv LD_LIBRARY_PATH
/u01/app/oracle/product/9.2.0.4/lib
LoadModule perl_module modules/mod_perl.so
PerlModule Apache2::compatPerlModule Apache::DBI
ScriptAlias /test/ "/web/cgi-bin/test/"
Options +ExecCGI
SetHandler perl-script PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Beginning of test.pl:
#!/usr/bin/perl -w
use strict;use Apache::DBI;use DBI;use DBD::Oracle;use CGI
qw(:standard);use Text::TagTemplate;use Storable;
BEGIN{ $ENV{'ORACLE_HOME'} =
'/u01/app/oracle/product/9.2.0.4'; $ENV{'ORACLE_USERID'} = 'foo/[EMAIL PROTECTED]'; $ENV{'ASSUME_KERNEL'} =
'2.4.19'; $ENV{'LD_LIBRARY_PATH'} =
'/u01/app/oracle/product/9.2.0.4/lib';}
Any
suggestions?
Thanks,
Steve
RE: [mp2] Env Variable / Oracle config problem
Thanks, but it did not work. I tried adding the PerlSetEnv lines before and after this line: LoadModule perl_module modules/mod_perl.so As well as inside the Directory element. Do you know where I can find a sample config/test script for setting up an Oracle database connection? Thanks, Steve -Original Message- From: Philippe M. Chiasson [mailto:[EMAIL PROTECTED] Sent: Friday, November 18, 2005 2:51 PM To: [EMAIL PROTECTED] Cc: modperl@perl.apache.org Subject: Re: [mp2] Env Variable / Oracle config problem Steve Duran wrote: > > > Hello, > > > > I'm trying to get a basic web app running under mod_perl2, using an > Oracle database connection. After I define the environment variables > listed below, the test script works fine from the command line, but > fails with the following error when I try to run it via the web > server. If I do not define the environment variables, I get the same > error on the command line as I do from the web server. > > > > I have tried different ways of defining the enviroment variables for > the script, but nothing seems to work. > > > > This is the error that I get from the web server (Apache 2) > > > > [Fri Nov 18 14:15:54 2005] [error] Can't load > '/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/Oracl > e/Oracle.so' > for module DBD::Oracle: libclntsh.so.9.0: > cannot open shared object file: No such file or directory at > /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230. > at /web/cgi-bin/test/test.pl line 6 > Compilation failed in require at /web/cgi-bin/test/test.pl line 6. > BEGIN failed--compilation aborted at /web/cgi-bin/test/test.pl line 6. > > > > > > This is and excerpt from httpd.conf: > > > SetEnv ORACLE_HOME /u01/app/oracle/product/9.2.0.4 > SetEnv ORACLE_USERID foo/[EMAIL PROTECTED] <mailto:foo/[EMAIL PROTECTED]> > SetEnv ASSUME_KERNEL 2.4.19 > SetEnv LD_LIBRARY_PATH /u01/app/oracle/product/9.2.0.4/lib Try this: PerlSetEnv ORACLE_HOME /u01/app/oracle/product/9.2.0.4 PerlSetEnv ORACLE_USERID foo/[EMAIL PROTECTED] <mailto:foo/[EMAIL PROTECTED]> PerlSetEnv ASSUME_KERNEL 2.4.19 PerlSetEnv LD_LIBRARY_PATH /u01/app/oracle/product/9.2.0.4/lib More details here: http://perl.apache.org/docs/1.0/guide/config.html#PerlSetEnv_and_PerlPassEnv Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
mailing list does NOT work
ListTO WHO IT MAY CONCERNGET ME OFF THIS LIST[EMAIL PROTECTED]
ModPerl programmer Job posting
Web application programmer 1099 contractor This position will work augment our project staff developing database-backed web applications and ecommerce websites using modPerl, apache and mySQL. Development work will include developing new projects and supporting existing projects; additionally you may be called upon to perform some system administration(unix/apache/mySQL). Requirements (seriously): 3+ years developing web, ecommerce and database applications with proven experience using the following technologies: Template::Toolkit, modPerl, Apache, MySQL. Experience juggling multiple, time-sensitive client projects while providing client focused, technical and customer support. Professional, direct client communication expected. Contractor must be able to work efficiently on your own to complete projects within a given deadline. Must be able to attend local (Denver) based meetings. This is a 1099 contract position requiring at least 1/2 time availability. Applicant will work at your location with your equipment and during regular business hours. Send resume and samples. Denver only -- [EMAIL PROTECTED] Visit us online at: http://www.summitdesign.net
Web programmer needed
Web application programmer 1099 contractor This position will work augment our project staff developing database-backed web applications and ecommerce websites using modPerl, apache and mySQL. Development work will include developing new projects and supporting existing projects; additionally you may be called upon to perform some system administration(unix/apache/mySQL). Requirements (seriously): 3+ years developing web, ecommerce and database applications with proven experience using the following technologies: Template::Toolkit, modPerl, Apache, MySQL. Experience juggling multiple, time-sensitive client projects while providing client focused, technical and customer support. Professional, direct client communication expected. Contractor must be able to work efficiently on your own to complete projects within a given deadline. Must be able to attend local (Denver) based meetings. This is a 1099 contract position requiring at least 1/2 time availability. Applicant will work at your location with your equipment and during regular business hours. Send resume and samples. Denver only -- [EMAIL PROTECTED] Visit us online at: http://www.summitdesign.net
Apache::DB - What am I doing wrong?
Can anyone tell me why I can't get Apache::DB to work with the following config? In the PERLDB block, if I change the Location to '/perl-status', the debugger activates fine. However, when its set to '/pa/session', I never see the debugger. I just see the output from the response handler in the browser. Also, if I change the Location to '/pa', the authentication handler works fine but I never see the debugger. Any suggestions? >From /etc/httpd/conf.d/perl.conf -- >LoadModule perl_module modules/mod_perl.so >PerlWarn on >PerlTaintCheck on > > > >use APR::Pool; >use Apache::DB (); >Apache::DB->init; > > > >PerlInitHandler Apache::DB > > > >#-* ># Perl Status Handler * >#-* > > SetHandler perl-script > PerlResponseHandlerApache2::Status > Order deny,allow > Deny from all > Allow from all > > >#*** ># ETS Handlers >#*** > >PerlModule Apache::DBI >PerlModule Apache::SessionManager >PerlModule Authen::Simple::DBI >PerlModule ETS::Authenticate >PerlModule ETS::Session > > > SetHandler perl-script > > PerlHeaderParserhandler Apache::SessionManager > > PerlSetVar SessionManagerTracking On > > PerlSetVar SessionManagerDebug 10 > > PerlSetVar SessionManagerExpire 3600 > > PerlSetVar SessionManagerInactivity 900 > > PerlSetVar SessionManagerStore Postgres > > PerlSetVar SessionManagerStoreArgs "DataSource => > dbi:Pg:dbname=control, UserName => apache, Commit => 1" > PerlSetVar SessionManagerSerialize Base64 > > > PerlAuthenHandler ETS::Authenticate > PerlSetVarETSAuthenticate_dsn dbi:Pg:dbname=control > PerlSetVarETSAuthenticate_username apache > PerlSetVarETSAuthenticate_statement "SELECT passwd FROM users WHERE > id = ?" > PerlSetVarETSAuthenticate_loginpage /login.html > AuthType Basic > AuthName "Protected Area" > Require valid-user > > > > SetHandler perl-script > PerlResponseHandler ETS::FormTest > Order deny,allow > Deny from all > Allow from all >
Re: Apache::DB - What am I doing wrong?
Yeah, it turns out it works using the fixup handler. Odd thing is, it works in the Init handler if I am debugging perl-status--just not anything else.
Nested Interpolation
Consider this:
my %names = (Bob => 'Robert Brower');
my $caption = 'Name: $names{Bob)';
print eval "qq|$caption|";
If you can't see it, there is a syntax error in $caption: closing
paren ) instead of brace }. The eval will produce no $@ and will
return the empty string.
As screwy as this looks, I have a very good reason for using this
capability. I have written a powerful code generation tool that
relies heavily on this.
Does anyone have any idea how to capture the syntax error in a case
like this?
Die Handler
In testing my mod_perl application, I would like to set up a die handler that will return the fatal errors I am getting to a custom "Server Error 500" page as well as write them to the log file. I am considering using Error.pm. Does anyone have any suggestions?
Re: Nested Interpolation
On Fri, 31 Mar 2006 08:48:20 -0500, Michael Peters
<[EMAIL PROTECTED]> wrote:
>
>
>Steve Thames wrote:
>> Consider this:
>>
>> my %names = (Bob => 'Robert Brower');
>> my $caption = 'Name: $names{Bob)';
>> print eval "qq|$caption|";
>>
>> If you can't see it, there is a syntax error in $caption: closing
>> paren ) instead of brace }. The eval will produce no $@ and will
>> return the empty string.
>>
>> As screwy as this looks, I have a very good reason for using this
>> capability. I have written a powerful code generation tool that
>> relies heavily on this.
>>
>> Does anyone have any idea how to capture the syntax error in a case
>> like this?
>
>It's not a syntax error, per say. Perl's string parser will look in
>double quoted strings for something that looks like a variable. If it
>couldn't be interpreted as a valid variable outside of the string it is
>ignored. It can't possibly through an error since there are a million
>different things that might look kinda like a variable, but aren't really.
Consider this:
my %names = (Bob => 'Robert Brower');
print eval "Name: $names{Bob)";
This produces:
syntax error at test.pl line 3, near "Bob)"
Missing right curly or square bracket at test.pl line 5, within string
In this construction:
my %names = (Bob => 'Robert Brower');
my $caption = 'Name: $names{Bob)';
print eval "qq|$caption|";
I am simply nesting the interpolation. The eval returns nothing and
$@ is empty. The syntax error is still happening which is why the
eval fails. I simply want to capture the error and report it.
Re: Nested Interpolation
On Fri, 31 Mar 2006 16:33:56 +0200, [EMAIL PROTECTED] (Tomas Zerolo)
wrote:
>On Fri, Mar 31, 2006 at 05:41:32AM -0800, Steve Thames wrote:
>> Consider this:
>>
>> my %names = (Bob => 'Robert Brower');
>> my $caption = 'Name: $names{Bob)';
>> print eval "qq|$caption|";
>[...]
>> Does anyone have any idea how to capture the syntax error in a case
>> like this?
>
>
>You mean something like...
>
> my %names = (Bob => 'Robert Brower');
> my $caption = 'Name: $names{Bob)';
> print eval "qq|$caption|";
> die $@ if $@
>
>giving:
>
> syntax error at (eval 1) line 1, near "Bob)"
> Missing right curly or square bracket at (eval 1) line 1, within string
>
>HTH
>-- tomas
Exactly right. Except $@ is empty in this construction--no error is
reported but the eval fails.
It has something to do with the way perl uses the setjmp and longjmp c
functions. I was reading something about that.
I'm trying to trap the syntax error.
Re: Nested Interpolation
Ok, thanks for you help guys. I've got the answer now and its
working.
Sorry for the post here. I was posting a couple of other questions
here and didn't think about this not being related to mod_perl.
Mod_perl is where I'm using it though.
Thanks again.
On Fri, 31 Mar 2006 05:41:32 -0800, Steve Thames <[EMAIL PROTECTED]>
wrote:
>Consider this:
>
> my %names = (Bob => 'Robert Brower');
> my $caption = 'Name: $names{Bob)';
> print eval "qq|$caption|";
>
>If you can't see it, there is a syntax error in $caption: closing
>paren ) instead of brace }. The eval will produce no $@ and will
>return the empty string.
>
>As screwy as this looks, I have a very good reason for using this
>capability. I have written a powerful code generation tool that
>relies heavily on this.
>
>Does anyone have any idea how to capture the syntax error in a case
>like this?
>
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC1.tar.gz WinXP/VC++ 6.0, Apache-2.2.2, Perl-5.8.8: - When I extracted the tarball, I found two extra directories (docs and man) besides libapreq2-2.08. I trust these won't be in the release version. - When I ran "perl Makefile.PL --with-apache2=C:/apache2" I got an error from win32/Configure.pl about Archive-Tar being missing, but this is not mentioned in the PREREQUISITES file and was not checked by test_prereq in Makefile.PL before calling this script. - When I run "nmake", the build process falls over at library/error.c with the error: NMAKE : fatal error U1073: don't know how to make '"C:\apache2\lib\libapr.lib"' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\Bin\NMAKE.EXE"' : return code '0x2' I assume this is the same problem that mod_perl-2.0 was having until Randy came to the rescue recently: the library in question is now called libapr-1.lib. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
Philip M. Gollucci wrote:
- When I ran "perl Makefile.PL --with-apache2=C:/apache2" I got an
error from win32/Configure.pl about Archive-Tar being missing, but
this is not mentioned in the PREREQUISITES file and was not checked by
test_prereq in Makefile.PL before calling this script.
Committed revision 408136
This doesn't seem to do anything for me. When I run Makefile.PL without
Archive-Tar present it just fails as before:
Can't locate Archive/Tar.pm in @INC (@INC contains: C:/perl5mt/lib
C:/perl5mt/site/lib .) at win32/Configure.pl line 11.
BEGIN failed--compilation aborted at win32/Configure.pl line 11.
system C:\perl5mt\bin\perl.exe win32/Configure.pl
--with-apache2-apxs="C:\apache2\bin\apxs.bat"
--with-perl="C:\perl5mt\bin\perl.exe" --with-apache2="C:/apache2"
--enable-perl-glue failed: 512 at Makefile.PL line 88.
Something like the attached patch at least gets the check done before
win32/Configure.pl is run, but even then it still carries on after the
failed check and crashes just the same:
Can't locate Archive/Tar.pm in @INC (@INC contains: C:/perl5mt/lib
C:/perl5mt/site/lib .) at build/version_check.pl line 42.
Please upgrade Archive::Tar first.
C:\perl5mt\bin\perl.exe win32/Configure.pl
--with-apache2-apxs="C:\apache2\bin\apxs.bat"
--with-perl="C:\perl5mt\bin\perl.exe" --with-apache2="C:/apache2"
--enable-perl-glue
Can't locate Archive/Tar.pm in @INC (@INC contains: C:/perl5mt/lib
C:/perl5mt/site/lib .) at win32/Configure.pl line 11.
BEGIN failed--compilation aborted at win32/Configure.pl line 11.
system C:\perl5mt\bin\perl.exe win32/Configure.pl
--with-apache2-apxs="C:\apache2\bin\apxs.bat"
--with-perl="C:\perl5mt\bin\perl.exe" --with-apache2="C:/apache2"
--enable-perl-glue failed: 512 at Makefile.PL line 92.
Shouldn't test_prereq stop Makefile.PL on failure rather than just warning?
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should check
it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
--- Makefile.PL.orig2006-05-22 09:09:18.0 +0100
+++ Makefile.PL 2006-05-22 09:17:21.645269900 +0100
@@ -41,6 +41,10 @@
test_prereq "Test::More";
}
+if (WIN32) {
+test_prereq "Archive::Tar";
+}
+
$opts .= "--debug " if (WIN32 and $args{debug});
delete @[EMAIL PROTECTED];
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC1
Randy Kobes wrote: On Fri, 19 May 2006, Steve Hay wrote: Philip M. Gollucci wrote:> Please download, test, and report back on the following> candidate tarball:> > http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC1.tar.gz WinXP/VC++ 6.0, Apache-2.2.2, Perl-5.8.8: - When I run "nmake", the build process falls over at library/error.c with the error: NMAKE : fatal error U1073: don't know how to make '"C:\apache2\lib\libapr.lib"'Stop.NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\Bin\NMAKE.EXE"' : return code '0x2' I assume this is the same problem that mod_perl-2.0 was having until Randy came to the rescue recently: the library in question is now called libapr-1.lib. The latter problem should now be fixed in the svn sources - thanks. Thanks, that's fixed the build error. I have one test script failing, though. When I ran "nmake test" from the top-level directory every test in glue\perl\t\apreq\cgi.t failed with a generic Windows popup error message saying "perl.exe has encountered a problem and needs to close...": Failed Test Stat Wstat Total Fail Failed List of Failed --- t\apreq\cgi.t 41 41 100.00% 1-41 Failed 1/10 test scripts, 90.00% okay. 41/191 subtests failed, 78.53% okay. When I cd into glue\perl and run "nmake test" from there I get different popups instead complaining about missing DLL's. If I add their locations to my PATH then I get the same "perl.exe has encountered..." messages as before. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC2
Philip M. Gollucci wrote: Please download, test, and report back on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC2.tar.gz All OK for me now on WinXP (Apache/2.2.2, Perl/5.8.8, mod_perl/SVN), except for the previously noted failures in t/apreq/cgi.t. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC2
Randy Kobes wrote: On Tue, 23 May 2006, Steve Hay wrote: Philip M. Gollucci wrote:> Please download, test, and report back on the following> candidate tarball:> > http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC2.tar.gz All OK for me now on WinXP (Apache/2.2.2, Perl/5.8.8, mod_perl/SVN), except for the previously noted failures in t/apreq/cgi.t. The problem with the t/apreq/cgi.t tests is that the Win32 apr and apu config scripts were using the old names of apr-config and apu-config, while for Apache/2.2 they should be called apr-1-config and apu-1-config (to agree with the convention on Unix). I've changed the apxs_win32.tar.gz archive on perl.apache.org to use these new names, and after reinstalling these utilities, and rebuilding and installing mp2 in the svn tree (there was a minor change needed there), all the libapreq2 tests now pass for me with perl-5.8.8 (ActivePerl 817) and Apache/2.2.2. I've installed the new apxs (0.4) and rebuilt and reinstalled mod_perl from SVN (rev 409101) and tried libapreq again: The t/apreq/cgi.t tests now pass OK, but I have an intermittent failure in some of the t/apreq/upload.t tests: sometimes I have some of tests 17-20 failing. The error log contains a couple of entries that say "The file exists."; I'm not sure if it is related or not. Do you see this at all, Randy? If I run the test suite half a dozen times then it almost always go wrong at least once. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE] libapreq2 2.08-RC5
Randy Kobes wrote: On Sun, 6 Aug 2006, Philip M. Gollucci wrote: Please download, test, and VOTE on the following candidate tarball: http://people.apache.org/~pgollucci/apreq2/libapreq2-2.08-RC5.tar.gz Builds fine and all tests pass on: - linux, Apache/2.0.55 prefork, mod_perl 2.02, perl-5.8.7 - Win32, Apache/2.2.2 winnt, mod_perl svn, perl-5.8.8 (ActiverPerl 817) Unfortunately, the problem on Win32 with running the glue/perl/t/apreq/upload.t test numerous times seems to be still with us; I still see sporadic temp files not being cleaned up. However, the tests still pass for me; it'd be interesting to see if Steve has problems. Builds OK for me (Apache/2.2.2, mod_perl SVN, perl-5.8.8) and initially "nmake test" gave me a few failures from upload.t. I re-ran it a few times and got some failures every time. Then I ran just that test itself from the glue/perl sub-dir: it failed a couple of times and then started working (dozens of times over). Returning to the top-level I now find that "nmake test" works there too! Weird. All the other tests passed OK. -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC1
Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-RC1 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc1.tar.gz All tests OK on Win32 using perl-5.8.8 and apache-1.3.34. -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE]: mod_perl-2.0.3 RC1
Philip M. Gollucci wrote: A release candidate for mod_perl 2.0.3 is now available for testing. Please grab the candidate from http://people.apache.org/~pgollucci/mp2/mod_perl-2.0.3-rc1.tar.gz All tests OK on Win32 with perl-5.8.8 and apache-2.2.2. -- Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [RELEASE CANDIDATE]: libapreq2 2.09-RC1
Philip M. Gollucci wrote:
Please download, test, and report back on the following
candidate tarball:
http://people.apache.org/~pgollucci/apreq2/libapreq2-2.09-rc1.tar.gz
All tests OK on Win32 (on a single run, at least--I'm not sure if the
previous problems with upload.t have gone away or not) using perl-5.8.8
and apache-2.2.2.
It took me a while to get it to work, though. It kept falling over part
of the way through the tests complaining that C:\apache2\bin\Apache.exe
could not be found (which is correct!--it is now called
C:\apache2\bin\httpd.exe in 2.2.2).
It turns out that it was getting this old path from an old
Apache/TestConfigData.pm file that was left over in my perl5/site/lib
folder, presumably from some time ago when I was using apache-2.0.x.
I simply blew away the old TestConfigData.pm file, ran the tests again
and all was well (with a new, updated TestConfigData.pm being generated
along the way).
mod_perl-2.0.3-rc1 didn't have this problem when I tested that with the
same old perl5 directory a little earlier today, so I'm not sure what
libapreq's problem was.
Would it be sensible for {mod_perl|Apache-Test|libapreq} (delete as
appropriate!) to delete any old TestConfigData.pm file when installing a
new version of one of those packages?
--
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should check
it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
