Re: Apache::Status bugfix ( :: doesn't play well in filenames)
thanks, but how about sending a patch using diff?
http://perl.apache.org/contribute/cvs_howto.html#Sending_Patches
sub noh_b_graph {
my $r = shift;
require B::Graph;
untie *STDOUT;
my $dir = $r-server_root_relative(
$r-dir_config(GraphDir) || logs/b_graphs);
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
## the line above you should add
## the line before it is # 516
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
--
__
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: T switch is ignored modperl2.0
Kent, Mr. John wrote:
Greetings,
I have put PerlSwitches -T in my httpd.conf file, yet keep getting the
following warning
in the server's error_log:
[Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with
'PerlSwitches -T' in httpd.conf
Any suggestions?
the cvs version or the next release won't complain anymore. currently -T
on shebang line is simply ignored, but will complain again in the future
when we will have a flag indicating whether the taint mode is on or not.
in perl 5.8.0 it's easy:
% perl5.8.0 -Te 'print ${^TAINT}'
in older Perls one need to parse PerlSwitches to find -T and set some
magic flag (was $Apache::__T in mod_perl 1.0).
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: hiding perl code
Michael Robinton wrote: see attached [...] BZS::License performs a similar load operation to BZS::Loader. First, however it looks for a hash pointer in the caller program called $ptr2_License. The hash contains the path to the License file and an optional 'private' key list of modules which will decrypt only with the 'private' key. BOR, a I thought that somebody has already said here that you cannot hide your perl code. if you have an access to the perl interpreter you can dump the source code after it was decrypted. wouldn't it be a good idea to add the truth to the POD so not to mislead the crowd? I've read through the doc but didn't see a word mentioning this little caveat. Shouldn't the module be renamed to BZS::Obscure::...? ;) __ 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: Mention LoadFile in the mp2 docs?
Alessandro Forghieri wrote: Greetings. From: http://perl.apache.org/docs/2.0/user/config/config.html#Enabling_mod_perl [...] Win32 users need to make sure that the path to the Perl binary (e.g., C:\Perl\bin) is in the PATH environment variable. [...] Is it not true that the directive LoadFile C:\foo\perl58.dll makes path modifications unnecessary? I guess the generic doc should simply redirect win32 users to http://perl.apache.org/docs/2.0/os/win32/config.html and not bother providing incomplete info. But I don't see that doc mentioning this issue. Randy? If so, it should perhaps be mentioned here. (With caveats, as situations where Registry scripts are handled by one - LoadFil-ed - perl version and CGI scriptse by another one - or not at all - would probably be confusing...). Cheers, alf -- __ 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: Win32: Apache2+modperl2 STDERR not going to error.log?
Alessandro Forghieri wrote: Greetings. I am using the binary distribution Apache/2.0.40-dev (Win32) mod_perl/1.99_05-dev Perl/v5.8.0 from uwinnipeg. OS is NTsp6 httpd.conf is basically unmodified. I have noticed that carp'ing or warn'ing or even printing to stderr from a Registry script does not send anything to error.log. The same from CGI does produce the expected log records - verified on printenv. Also I am under the impression that the same does *NOT* happen on Win2K, but I cannot confirm it right now. Is this a known issue with this version, a by-design thing, or is it just me? FWIW, there are no problems on linux. Do you have the same problem with v5.6.1? Meanwhile try using the logging methods if possible: http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.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
Re: Apache::Reload - filtering include directories
[...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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: Segmentation fault
Vitor wrote: Hello Folks, I am having a big problem here. While i try to open a new Mail::CClient connection, i get these message : [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation fault (11) I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without shared libraries, and HTML::Mason templating system. I don't know if is a callback problem, because to login, Mail::CClient uses a login callback. It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ 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: Re: Problems using Perl v 5.8
Hi, thanks for your help. Now everything works fine using mod_perl 1.27. :) Lino .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR - Istituto di Elaborazione della Informazione Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 E-mail: [EMAIL PROTECTED] .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- -Messaggio originale- Da: Stas Bekman [mailto:[EMAIL PROTECTED]] Inviato: martedi 30 luglio 2002 05.21 Cc: Pasquale Pagano; Modperl Oggetto: Re: Problems using Perl v 5.8 [EMAIL PROTECTED] wrote: Does it help to update mod_perl to 1.27? and if not, please send to the list the shortest possible script that reproduces the problem. Pasquale Pagano [EMAIL PROTECTED] on 07/29/2002 12:35:10 PM To: Modperl [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Problems using Perl v 5.8 Hi, We have some problems using: 1) Perl v 5.8 2) Mod_Perl v 1.26 3) Apache v 1.3.26 In particular: a) if we use simple CGI, everything works fine; b) if we use a custom handler for mod_perl, everything works fine; but if we try to use our CGI via Apache::Registry or Apache::PerlRun handler the code is ran correctly but we are able to send back to the browser only the HTTP header (everything else is missed). Here below an example of the http response -__- HTTP/1.1 200 OK Date: Mon, 29 Jul 2002 17:20:02 GMT Server: Apache/1.3.26 (Unix) mod_perl/1.26 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -__- Any of you have some hints?? Any help will be welcome, Regards, Lino PS: The same code works fine using Perl v 5.7.2. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR - Istituto di Elaborazione della Informazione Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 E-mail: [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
Re: apache mod_perl + suid question
[EMAIL PROTECTED] wrote: Hello, I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ 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
apache/mod_perl help
I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI /Location PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel
Apache::Status patch, in diff -u format (finally ;)
Index: Status.pm
===
RCS file: /home/cvspublic/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
diff -u -r1.26 Status.pm
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 30 Jul 2002 12:39:07 -
-514,6 +514,7
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
my $type = dot;
my $file = $dir/$thing.$$.gif;
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
RES: Segmentation fault
Hello Stas, I will look for those information. Anyway, it does not works under pure mod_perl too. Regards, Vitor -Mensagem original- De: Stas Bekman [mailto:[EMAIL PROTECTED]] Enviada em: terca-feira, 30 de julho de 2002 06:04 Para: Vitor Cc: [EMAIL PROTECTED] Assunto: Re: Segmentation fault Vitor wrote: Hello Folks, I am having a big problem here. While i try to open a new Mail::CClient connection, i get these message : [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation fault (11) I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without shared libraries, and HTML::Mason templating system. I don't know if is a callback problem, because to login, Mail::CClient uses a login callback. It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: apache mod_perl + suid question
Thanks a lot. That really does help. regards, -Tushar -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 6:36 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: apache mod_perl + suid question [EMAIL PROTECTED] wrote: Hello, I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ 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: Apache2 CWD Non-threaded MPM
Joshua Bernstein wrote: Hey All, After much hassle, I blew away my threaded MPM under Apache2 because mod_perl didn't seem to be accepting or processing the . (period) in my @INC path so that scripts called like: require blah.cgi were not being found in the include path. I understand there are still issues with SafeCWD'ing in a threading enviroment, but now that the MPM is prefork, it isn't threaded anymore. Any reason why mod_perl 2, still doesn't recognize the . in my @INC path? You are talking about ModPerl::Registry, not mod_perl 2.0 in general. ModPerl::Registry will always do the same thing, be it the prefork mpm or the threaded mpm. Because the same code should run identically no matter what the mpm is used. Therefore if chdir() cannot be used with the threaded mpm it won't work with the prefork mpm as well. Solution 1: Subclass ModPerl::Registry as ModPerl::RegistryPreFork and do whatever is fine with prefork. Subclassing the new registry family is extremely easy, though the API hasn't been frozen yet. See ModPerl::RegistryCooker for more info. Solution 2: Arthur Bergman is working on ex::threads::safecwd, which should resolve the problem for threaded mpms. So once it's available we can use chdir() in ModPerl::Registry again. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apache/mod_perl help
Dinesh Patel wrote: I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! It's too early to upgrade to mod_perl 2.0. Not all features are implemented (which is the case with Perl sections). For more info see: http://perl.apache.org/docs/2.0/user/index.html I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI /Location PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
Harry Danilevsky wrote: Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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 -- __ 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: I can see Apache.pm, why can't he?
Dennis Daupert wrote: What's up with this? I'm trying to load Apache::DBI on startup. I have apache and mod_perl installed, and running ok, and have installed additional modules, including the Apache::Bundle. When I put the line in mod_perl.conf, PerlModule Apache::DBI I can't start the web server. Dennis: Doctor, I think my server is sick, it cannot start Doctor: Does it have a high temperature? http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
I certainly agree with attaching a common prefix to a library, but what if I am already dealing with a bunch of modules written without prefix, and enough application code using those packages ? I suppose I could change the code, or alias names in symbol table, or do some other trick; I just figured that one extra directive, plus one patched line was a cheap solution to my problems. I guess if nobody else sees any value in it, I'll just keep the private patched version for myself :-) Stas Bekman wrote: Harry Danilevsky wrote: Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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
Trouble with RegistryCooker.pm modper2.0
Greetings, Today, 30-July-02, :Re-built both bleedperl and modperl from cvs per http://perl.apache.org/docs/2.0/user/install/install.html When attempting to run modperl get: [Tue Jul 30 13:08:08 2002] [error] [client 192.160.159.24] Use of uninitialized value in concatenation (.) or string at /users/webuser/bleedperl/lib/site_perl/5.8.0/i686-linux-thread-multi/ModPerl /RegistryCooker.pm line 549. This seems to be related to PerlSwitches -T which was in earlier releases but now is commented out Thanks, John Kent
Re: Trouble with RegistryCooker.pm modper2.0
Kent, Mr. John wrote: Greetings, Today, 30-July-02, :Re-built both bleedperl and modperl from cvs per http://perl.apache.org/docs/2.0/user/install/install.html When attempting to run modperl get: [Tue Jul 30 13:08:08 2002] [error] [client 192.160.159.24] Use of uninitialized value in concatenation (.) or string at /users/webuser/bleedperl/lib/site_perl/5.8.0/i686-linux-thread-multi/ModPerl /RegistryCooker.pm line 549. This seems to be related to PerlSwitches -T which was in earlier releases but now is commented out Mea Culpa, please try again the cvs version, should be ok now. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Dennis Haney wrote: The bias in the test is even a little slanted towards the JSP benchmarks since the trivial connection pooling I used there is nothing like the Apache::DBI overhead in the mod_perl test, when I could have just used a persistent global $dbh instead. ( maybe I should? ) I believe you should. It is the most common setup using mod_perl, if you are concerned about performance, anyway. I think you got confused by the wording. The most common setup with mod_perl is to use Apache::DBI, which is what he used in the test. To answer the original question, I don't think Apache::DBI is much overhead at all. It amounts to little more than a hash lookup. Certainly less work than the the thread synchronization required for connection pooling. - Perrin
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Perrin Harkins wrote: To answer the original question, I don't think Apache::DBI is much overhead at all. It amounts to little more than a hash lookup. Certainly less work than the the thread synchronization required for connection pooling. My only problem with Apache::DBI for a benchmark is its default ping of the db per connect(). For a benchmark that is little more that a ping itself, this might not be fair to cause 2 pings. In this light, I might want to just use a global like: $dbh ||= DBI-connect(); I just did a quick test, and these were the results: Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - mod_perl HelloDB MySQL Apache::DBI my_hellod 451.3 9042 20.040.002216 191 16092 mod_perl HelloDB MySQL Global $dbh my_hellod 570.2 11418 20.020.001754 191 15296 My question is is this a fair optimization for a benchmark like this. I tend to not over optimize the benchmarks as a rule, but I spent hours ( 12 lines of code :) ) writing an overly simple database connection pooling manager for the JSP benchmarks where a standard one seems to be lacking in JDBC JNDI, so I'm not sure using a mod_perl global instead of Apache::DBI would be skewing things. The PHP test I had to do nothing, connection persistence is enabled by default. Thanks for the feedback still looking for more! --Josh Josh Chamas, Founder phone:714-625-4051 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Fwd: Re: Apache::DBI as a prerequisite
Could you please take a look at this problem? Thanks.
- Forwarded message from Stas Bekman [EMAIL PROTECTED] -
Date: Mon, 29 Jul 2002 09:56:05 +0800
From: Stas Bekman [EMAIL PROTECTED]
Reply-To: Stas Bekman [EMAIL PROTECTED]
Subject: Re: Apache::DBI as a prerequisite
To: Simon Perrault [EMAIL PROTECTED]
Simon, please repost to the modperl list and we will discuss it there.
Thanks.
Simon Perrault wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported. This test suite is simple broken.
...
All Apache:: module authors should be moving to use the new Apache::Test
framework soon, since it lets you test the code under running mod_perl
server and works with both versions of httpd/mod_perl.
This is exactly my situation. I develop a module which requires Apache::DBI,
so I include it in my Makefile.PL like this:
WriteMakefile(
'PREREQ_PM'= {
'Apache::DBI' = 0,
},
);
But that prints a warning because Apache::DBI can't find Apache::module(),
which is only available under mod_perl.
My question:
1) Can you tell me (or guide me toward some information) how I can properly
add Apache::DBI as a prerequisite so that it doesn't print a warning (which
is the subjet of 90% of user emails)?
2) How can I test my module running Apache::DBI with Apache::Test?
Thanks a lot
- --
Simon Perreault [EMAIL PROTECTED]
Web: http://www.linuxquebec.com/~nomis80
PGP: $Web/nomis80.gpg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9QwYAqaCdwBMK2KkRAt+pAJ9knR94Tz5jmBFCyO/hL/fNWwHzmwCfZSl0
66Chb76wE6YcgR6JbxYpQEc=
=4xfy
-END PGP SIGNATURE-
--
__
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
- End forwarded message -
--
Simon Perreault [EMAIL PROTECTED]
Web: http://www.linuxquebec.com/~nomis80
PGP: $Web/nomis80.gpg
Re: make test problem error 111
Hi, I reinstalled perl 5.6.1 with the following modules - HTML-Parser-3.26.tar.gz - libnet-1.12.tar.gz - libwww-perl-5.65.tar.gz - MIME-Base64-2.12.tar.gz - URI-1.19.tar.gz - Digest-MD5-2.20.tar.gz and followed the instructions I used before to install apache,mod_perl + mod_ssl and it worked for me... Thanks for your help Padraic - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Padraic Woods [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 30, 2002 4:35 AM Subject: Re: make test problem error 111 Padraic Woods wrote: Hi, I'm trying to install apache + mod_perl + mod_ssl but get a error after running make test, I've tried skiping the make test but get a segmentation fault when I try starting apache. [...] ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log () gets absurdforkletting apache warm up...\c that's an interesing message: gets absurdfork where does it come from? no error_log is bad, have you tried following the install notes in: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___op enssl_ if you get a segfault, please follow the instructions at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Subject: Re: hiding perl code
You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Be it BZS::VeryObscure or BZS::VeryVeryObscure, all I was asking for is to tell the thruth in the docs probably somewhere at the top. I agree that for certain purposes this module may satisfy those who use it, but not all of them. __ 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: Fwd: Re: Apache::DBI as a prerequisite
Simon Perreault wrote:
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported. This test suite is simple broken.
...
All Apache:: module authors should be moving to use the new Apache::Test
framework soon, since it lets you test the code under running mod_perl
server and works with both versions of httpd/mod_perl.
This is exactly my situation. I develop a module which requires Apache::DBI,
so I include it in my Makefile.PL like this:
WriteMakefile(
'PREREQ_PM'= {
'Apache::DBI' = 0,
},
);
But that prints a warning because Apache::DBI can't find Apache::module(),
which is only available under mod_perl.
My question:
1) Can you tell me (or guide me toward some information) how I can properly
add Apache::DBI as a prerequisite so that it doesn't print a warning (which
is the subjet of 90% of user emails)?
2) How can I test my module running Apache::DBI with Apache::Test?
I'll answer these in reverse:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is released.
1) That's an interesting problem. It seems that nobody has asked this
question before. Here is my take on it. If you like this solution I'll
add it to the docs.
Makefile.PL
---
use ExtUtils::MakeMaker;
# set prerequisites
my %prereq = (
Foo = 1.56,
);
# Manually test whether Apache::DBI is installed and add it to the
# PREREQ_PM if it's not installed, so CPAN.pm will automatically fetch
# it. If Apache::DBI is already installed it will fail to get loaded by
# MakeMaker because it requires the mod_perl environment to load.
eval { require Apache::DBI };
if ($@ $@ !~ /Can't locate object method/) {
$prereq{Apache::DBI} = '';
}
WriteMakefile(
NAME = 'Apache::SuperDuper',
VERSION_FROM = 'SuperDuper.pm',
PREREQ_PM = \%prereq,
# ...
);
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Status patch, in diff -u format (finally ;)
DH wrote:
Index: Status.pm
===
RCS file: /home/cvspublic/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
diff -u -r1.26 Status.pm
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 30 Jul 2002 12:39:07 -
@@ -514,6 +514,7 @@
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
my $type = dot;
my $file = $dir/$thing.$$.gif;
Thanks, committed
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl2 DBD::Oracle problem
Atsushi Fujita wrote:
Hi all,
I am trying to use DBD::Oracle1.12 on mod_perl2.
But it doesn't work fine.
It shows error as following in error_log at $dbh = DBI-connect.
[error_log]
DBI-connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
ORACLE_HOME and NLS settings etc. at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
[Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot connect:
(UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
NLS settings etc.at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
[test1.cgi]
use DBI;
my $dsn = 'dbi:Oracle:';
my $user = 'username/password';
my $password = '';
$ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
$ENV{'ORACLE_SID'} = 'ynt0';
$ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
print ORACLE_HOME=$ENV{'ORACLE_HOME'}br\n;
print ORACLE_SID=$ENV{'ORACLE_SID'}br\n;
print NLS_LANG=$ENV{'NLS_LANG'}br\n;
print DSN=$dsn$ENV{'ORACLE_SID'}br\n;
$dbh = DBI-connect($dsn$ENV{'ORACLE_SID'}, $user, $password)
or die Cannot connect: .$DBI::errstr;
...
At first, I suspect that the reason is %ENV in this script.
But I set surely, and this output as following.
[Broser output HTML]
ORACLE_HOME=/u01/app/oracle/product/9.0.1
ORACLE_SID=ynt0
NLS_LANG=japanese_japan.ja16euc
DSN=dbi:Oracle:ynt0
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request.
And if I turned off the mod_perl, it works fine on normal CGI-script.
This error occurred only mod_perl.
(I tested mod_perl1.26 apache 1.3.26, it worked fine...)
My machine is as following.
- perl5.6.1(non thread)
- DBI-1.30
- DBD-Oracle-1.12
- mod_perl1.99_04(DSO build)
- apache2.0.39(prefork)
[httpd.conf](is this wrong??)
LoadModule perl_module modules/mod_perl.so
...
IfModule mod_perl.c
PerlModule ModPerl::Registry
Location /cgi-bin
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
/IfModule
Do you suggest that %ENV is getting lost along the way? Or can it be
some other problem? I don't have Oracle to test with. Or can you think
of some other way to reproduce the problem without depending on Oracle
being installed?
Can you please test with the following two approaches:
1.
instead of using ModPerl::Registry, use Apache::Registry. Of course
configure Location to use Apache::Registry.
use Apache::compat;
use Apache::Registry; # hopefull you have mod_perl 1.0 installed
any change when you use the Apache::Registry from 1.0? Currently the
only difference (mainly) is that ModPerl::Registry doesn't chdir() into
the script's dir. (which eventually will change)
2. use a mod_perl handler
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Josh Chamas wrote: My only problem with Apache::DBI for a benchmark is its default ping of the db per connect(). Oh, you're right I wasn't thinking about that. It is important in a benchmark to be testing equivalent functionality as much as possible, although it's very difficult to do. I spent hours ( 12 lines of code :) ) writing an overly simple database connection pooling manager for the JSP benchmarks where a standard one seems to be lacking in JDBC JNDI I thought that JDBC had a pooling capability now. I also thought Resin had something built in. I would use those if possible. Stick with Apache::DBI for mod_perl though. I would never tell anyone to roll their own database persistence for performance instead of using Apache::DBI. Pinging the database connection is good, and all systems should do it if they don't already. - Perrin
Re: $r-dir_config-(un)set issue...
simran wrote:
Hi All,
I have a situation where it is convinent for me to define a global
PerlSetVar in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
httpd.conf
--
Perl
use Apache::Server;
Apache-server-dir_config-unset(MyVar);
/Perl
-
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-
code sample 1
--
1. sub handler {
2.my $r = instance Apache::Request(shift);
3.
4.$r-dir_config(MyVar = undef);
5.
6.$r-dir_config-unset(MyVar);
7.
8.$r-dir_config-set(MyVar = undef);
9.
10. }
s/$r-dir_config/$r-server-dir_config/?
What's really needed is probably PerlUnSetEnv.
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a true value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Ideas anyone?
simran.
--
__
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: $r-dir_config-(un)set issue...
Does that mean that
$r-dir_config is not the same as $r-server-dir_config ?
A PerlUnsetVar would indeed be very handy... as would PerlUnsetEnv :-)
On Wed, 2002-07-31 at 12:50, Stas Bekman wrote:
s/$r-dir_config/$r-server-dir_config/?
What's really needed is probably PerlUnSetEnv.
simran wrote:
Hi All,
I have a situation where it is convinent for me to define a global
PerlSetVar in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
httpd.conf
--
Perl
use Apache::Server;
Apache-server-dir_config-unset(MyVar);
/Perl
-
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-
code sample 1
--
1. sub handler {
2.my $r = instance Apache::Request(shift);
3.
4.$r-dir_config(MyVar = undef);
5.
6.$r-dir_config-unset(MyVar);
7.
8.$r-dir_config-set(MyVar = undef);
9.
10. }
s/$r-dir_config/$r-server-dir_config/?
What's really needed is probably PerlUnSetEnv.
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a true value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Ideas anyone?
simran.
--
__
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
Problems with Apache/Mod_perl Server
Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] 3. Then I backup into the apache_1.3.26 directory and issue make install I am congratulated for a successful installation. 4. The I issue (as root) /usr/local/apache/bin/apachectl start and the error message from the /usr/local/apache/logs/error_log [Tue Jul 30 16:01:52 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Apache.pm failed to load!. [Tue Jul 30 16:37:55 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Tue Jul 30 16:37:55 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. [Wed Jul 31 12:27:57 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Wed Jul 31 12:27:57 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. I think the failure is due to incomplete mod_perl installation. As I pointed out earlier, the earlier versions of mod_perl and apache were installed successfully. I was configuring the httpd.conf file to run some cgi scripts which did not execute very well but I think can fix that. I've spent the past 48 hours trying to trouble shoot the trouble as much as I can but access to information is so very frustrating from this end of the world.. I am using Perl 5.6.1 on Linux 7.1. I installed the mod_perl and apache packages which came with the box but did not use them so had them unstalled. Any pointers to where I can start meaningful trouble-shooting would be greatly appreciated. Thanks in advance, Alfred Vahau School of Natural and Physical Sciences Uni. PNG
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] [...] I think the failure is due to incomplete mod_perl installation. of course. You run: make make test make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl 2.0 api and extending method in Apache
Alexandre Dulaunoy wrote:
Hello,
I have look around the documentation of mod_perl 2.0 and I'm looking if
it's possible with the current mod_perl API to add a method (like GET,
HEAD) in apache to extend the functionnaly of the HTTP server ?
There is also some possibility with the new framework to add new protocol
(like the echo example in the mod_perl doc). But I just want to extend
existing (or add new) method... Is it possible ?
I'm not sure what you mean by extending, but look at mod_dav which
extends the HTTP protocol: modules/dav/main/mod_dav.c (inside the
httpd-2.0 repository).
In mod_perl 2.0 you can support new request methods, by simply
registering them. e.g. let's support the method 'TNT' in the response
handler:
Location /extend
SetHandler perl-script
PerlResponseHandler Apache::Extend
/Location
package Apache::Extend;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Const -compile = 'OK';
use constant METHNAME = 'TNT';
sub handler {
my $r = shift;
$r-content_type('text/plain');
Apache::method_register($r-pool, METHNAME);
print Called with Method: . $r-method;
Apache::OK;
}
1;
Now, let's call:
perl -le 'require LWP::UserAgent; print
LWP::UserAgent-new-request(HTTP::Request-new(GET,
http://localhost:8002/extend/;))-content;'
Called with Method: GET
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with Apache/Mod_perl Server
Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. Thanks, Alfred, Stas Bekman wrote: Alfred Vahau wrote: Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] [...] I think the failure is due to incomplete mod_perl installation. of course. You run: make make test make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ 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
test
test
cvs commit: modperl Changes
stas2002/07/30 19:10:16
Modified:lib/Apache Status.pm
.Changes
Log:
fix Apache::Status to not use :: in filenames, which is not allowed on
certain OSs
Submitted by: DH [EMAIL PROTECTED]
Revision ChangesPath
1.27 +1 -0 modperl/lib/Apache/Status.pm
Index: Status.pm
===
RCS file: /home/cvs/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 31 Jul 2002 02:10:15 - 1.27
@@ -514,6 +514,7 @@
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # :: is not allowed in the filename on some OS
my $type = dot;
my $file = $dir/$thing.$$.gif;
1.654 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.653
retrieving revision 1.654
diff -u -r1.653 -r1.654
--- Changes 19 Jun 2002 16:31:52 - 1.653
+++ Changes 31 Jul 2002 02:10:16 - 1.654
@@ -10,6 +10,9 @@
=item 1.27_01-dev
+fix Apache::Status to not use :: in filenames, which is not allowed on
+certain OSs [DH [EMAIL PROTECTED]]
+
various cygwin fixes [Per Einar Ellefsen [EMAIL PROTECTED]]
fix to compile with 5.8.0 on win32 [Randy Kobes [EMAIL PROTECTED]]
