Re: [PATCH] in memory $Application object for Apache::ASP
Joel Reed wrote:
this may be a dumb patch to Apache::ASP (at least it is my first).
Rationale:
i have the following issues with the current implementation of $Application
1. everything you store in $Application-{foo} must be
serializable my MLDBM. (right?) i have SWIG'd c++ classes for
which this will not work.
2. limitation #1 seems to limit Apache:ASP's usefulness as a
cross-platform solution to ActivePerl/IIS/ASP scripts you
want to move to linux, etc. i want to do this - not sure if
this is really a key thing for joshua though...
...
What you are talking about is just a global that you access
in your scripts. You could declare this in your global.asa
with
use vars qw($Application2);
Then just use it like $Application2-{key} = $value;
I use this kind of in process data caching all the time,
and you will see that Apache::DBI does something similar.
What you don't get here is interprocess communication
which is what the use of $Application is geared for, that
the data is stored is some process neutral location, so
web requests may access the data independent of the httpd
process they are coming from.
--Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Another problem compiling Apache-Scoreboard-0.08
On Tue, 21 Mar 2000, Charles Day wrote: Stas, Trying to get Apache::VMonitor up, I'm getting the same error Gustav saw with Apache::Scoreboard, but I'm running your gcc and Linux 2.2.12. Did you ever figure this one out? Get the latest Apache::Scoreboard 0.10 Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Here's my error message... [root@razor Apache-Scoreboard-0.10]# make mkdir blib mkdir blib/lib mkdir blib/lib/Apache mkdir blib/arch mkdir blib/arch/auto mkdir blib/arch/auto/Apache mkdir blib/arch/auto/Apache/Scoreboard mkdir blib/lib/auto mkdir blib/lib/auto/Apache mkdir blib/lib/auto/Apache/Scoreboard mkdir blib/man3 cp lib/Apache/ScoreboardGraph.pm blib/lib/Apache/ScoreboardGraph.pm cp Scoreboard.pm blib/lib/Apache/Scoreboard.pm make[1]: Entering directory `/usr/src/Apache-Scoreboard-0.10/Dummy' mkdir ../blib/arch/auto/Apache/DummyScoreboard mkdir ../blib/lib/auto/Apache/DummyScoreboard cp DummyScoreboard.pm ../blib/lib/Apache/DummyScoreboard.pm /usr/bin/perl -I/usr/lib/perl5/5.00503/i586-linux -I/usr/lib/perl5/5.00503 /usr/lib/perl5/5.00503/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.00503/ExtUtils/typemap -typemap /usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/typemap -typemap typemap DummyScoreboard.xs xstmp.c mv xstmp.c DummyScoreboard.c Please specify prototyping behavior for DummyScoreboard.xs (see perlxs manual) cc -c -I../ -I/usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/include -I/usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/include/modules/perl -I/usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/include/include -I/usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/include/os/unix -Dbool=char -DHAS_BOOL -O2-DVERSION=\"0.04\" -DXS_VERSION=\"0.04\" -fpic -I/usr/lib/perl5/5.00503/i586-linux/CORE DummyScoreboard.c In file included from DummyScoreboard.xs:2: /usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/include/include/scoreb oard.h:149: field `start_time' has incomplete type /usr/lib/perl5/site_perl/5.005/i586-linux/auto/Apache/include/include/scoreb oard.h:150: field `stop_time' has incomplete type make[1]: *** [DummyScoreboard.o] Error 1 make[1]: Leaving directory `/usr/src/Apache-Scoreboard-0.10/Dummy' make: *** [subdirs] Error 2 List: apache-modperl Subject: Re: Another problem compiling Apache-Scoreboard-0.08 From: Stas Bekman Date: 2000-01-23 12:26:28 On Sun, 23 Jan 2000, Gustav Kristoffer Ek wrote: I got the folowing error when compiling Apache::Scoreboard 0.08: make make[1]: Entering directory `/usr/src/cpan/build/Apache-Scoreboard-0.08/Dummy' cc -c -I../ -I/usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include -I/usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include/modules/perl -I/usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include/include -I/usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include/regex -I/usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include/os/unix -Dbool=char -DHAS_BOOL -I/usr/local/include -O2 -DVERSION=\"0.04\" -DXS_VERSION=\"0.04\" -fpic -I/usr/lib/perl5/5.00503/i686-linux/CORE DummyScoreboard.c In file included from DummyScoreboard.xs:2: /usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include/include/scoreb oard.h:150: field `start_time' has incomplete type /usr/lib/perl5/site_perl/5.005/i686-linux/auto/Apache/include/include/scoreb oard.h:151: field `stop_time' has incomplete type make[1]: *** [DummyScoreboard.o] Error 1 make[1]: Leaving directory `/usr/src/cpan/build/Apache-Scoreboard-0.08/Dummy' make: *** [subdirs] Error 2 Line 150 and 151 in scoreboard.h looks like: struct timeval start_time; struct timeval stop_time; I'm using modperl 1.21_01-dev and perl 5.00503 on a i386 running linux 2.3.20. Gustav, I can build this version with no problems using the same environment, but kernel 2.2.12. I thought that may be the /usr/src/linux/include/linux/time.h has been changed, but according to http://lxr.linux.no/diff/include/linux/time.h?v=2.3.28;diffvar=v;diffval=2. 2.12 it's the same. So I believe the difference you and me might have is in compiler version. Mine is: (cc == gcc) gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Hope this helps... ___ Stas Bekman mailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org single o- + single o-+ = singlesheaven http://www.singlesheaven.com [ __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide/
Problem re-directing STDOUT in system() calls
Hi, I've had this problem before, but never got to the bottom of it. I'm cursed with a situation in which I need to run some .exe file from a (mod)perl script. The program concerned is a console application so it just writes its output on STDOUT. I need to re-direct that output to a temporary file, and then read the file in to process in the perl script. Sounds simple enough, and it works fine running Apache without mod_perl. But as soon as I put mod_perl into the equation I find that I can't re-direct STDOUT in the system() call. The following script illustrates the problem: print "Content-Type: text/html\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe D:\\Temp\\ip.txt"; print "The system() call exited with status $status.\n"; Without mod_perl this works fine: "ip.txt" is created and $status is 0. But with mod_perl "ip.txt" is not created, $status is 256 and the following line appears in error.log: The handle could not be opened during redirection of handle 1. Can anyone help? My setup is as follows: - NT 4 Workstation, Service Pack 6 - Perl 5.005_03 built with VC++ 6 and the Makefile options: CFG = Optimize USE_PERLCRT PERL_MALLOC - Apache 1.3.12 built with VC++ 6 - mod_perl 1.22 built with VC++ 6 - D: is a local disk which I have full access to I've found that the problem goes away if I downgrade to Apache 1.3.6 and keep everything else the same! Steve Hay
Re: More segfault problems
I configured on the quick and dirty with DO_HTTPD=1 APACHE_SRC=/usr/local/src/apache_1.3.12 USE_APACI=1 PREP_HTTPD=1 I can't find any documentation for what RULE_EXPAT does, the only occurrence at all is in Apache src/Configure, where it seels to compile in the expat lite library. I have since developed the code quite a way past that segfault, although I have had several more reproducible ones, mostly related to some particular feature ofmy Perl. S. On Tue, 28 Mar 2000, Doug MacEachern wrote: On Fri, 24 Mar 2000, Shevek wrote: Now we get rid of the DOM tree. 44 $document-dispose; And the child segfaults. But if I don't have the dumper, that does not happen. What is the best way to get around this? Is undefining $d an appropriate technique? did you configure apache with RULE_EXPAT=no ? -- Shevek GM/CS/MU -d+ H+++ s+: !g p2 au0 !a w+++ v-(---) C$ UL$ UB+ US+++$ UI+++$ P++ L$ 3+ E--- N K- !W(-) M(-) !V -po+ Y+ t+ 5++ !j !R G' !tv b+++ D++ B--- e+ u+* h++ f? r++ n y? Recent UH+++ UO+ UC++ U?+++ UV++ and collecting.
Re: [new module] proposal Apache::DebugHeaders
On Wed, 29 Mar 2000, Francesc Guasch wrote: A very easy way of create Makefile.PL and module files and directories is typing this: h2xs -X -n My::Object Please don't do that for mod_perl. You get autoloading that way, which means mod_perl can't load the methods at start time, which means they aren't shared. Use: h2xs -X -A -C -n My::Object -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Modperl 1.22 and Perl 5.6.0
On Tue, 28 Mar 2000, Doug MacEachern wrote: On Fri, 24 Mar 2000, Ken Kosierowski wrote: What is the best way to compile the new Perl 5.6.0 with Modperl 1.22? same way you compile 5.005 with mod_perl Should I use the 5.005 compatible flags or start from scratch and recompile the modules I use? you don't need the 5.005 compat flags to build mod_perl-1.22 Are there performance issues using the 5.005 compat mode? not sure, doubt it though. What about malloc and malloc flags -- same as what the Guide recommends? i the guide recommendations (TWO_POT_OPTIMIZE, etc) are the default since 5.005. i think linux still defaults to system malloc, you might want to configure Perl with -Dusemymalloc Wait, doesn't usemymalloc mean to use the system's native malloc? This from INSTALL: "To build without perl's malloc, you can use the Configure command sh Configure -Uusemymalloc" On Linux 2.2, Perl uses its own malloc by default. To use the native malloc, specify -Dusemymalloc. It might be amusing to compare the two, as Linux has a very fast malloc implementation. BTW, I couldn't find reference to usemymalloc in the guide. Cheers, Jeffrey
Re: [new module] proposal Apache::DebugHeaders
On Tue, 28 Mar 2000, Geoffrey Young wrote: ok, this isn't all that clever, but recently I got tired of writing loops of warnings to debug headers_in and headers_out over and over again... Then you should look at the Apache::DumpHeaders module. :) Major feature is that it can be configured to only dump traffic from certain IP addresses. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
RE: [new module] proposal Apache::DebugHeaders
actually, http://perl.apache.org/src/apache-modlist.html recommends h2xs -AX -n Apache::YourPackageName what's the -C option - it isn't in my perldoc h2xs? --Geoff -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 29, 2000 4:40 AM To: Francesc Guasch Cc: '[EMAIL PROTECTED]' Subject: Re: [new module] proposal Apache::DebugHeaders On Wed, 29 Mar 2000, Francesc Guasch wrote: A very easy way of create Makefile.PL and module files and directories is typing this: h2xs -X -n My::Object Please don't do that for mod_perl. You get autoloading that way, which means mod_perl can't load the methods at start time, which means they aren't shared. Use: h2xs -X -A -C -n My::Object -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
[Patch] Apache::DB on Win32
Hi Doug, the following patch allows Apache::DB to be used on Win32 Systems: In DB.xs wrap the SIGINT call at the last line inside a conditional, like: #ifndef WIN32 if (ApacheSIGINT) (*ApacheSIGINT)(SIGINT); #endif Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: [new module] proposal Apache::DebugHeaders
-Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 29, 2000 6:30 AM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: Re: [new module] proposal Apache::DebugHeaders On Tue, 28 Mar 2000, Geoffrey Young wrote: ok, this isn't all that clever, but recently I got tired of writing loops of warnings to debug headers_in and headers_out over and over again... Then you should look at the Apache::DumpHeaders module. :) whoops - I missed that one (looks recent, too :) actually, since posting the code I've expanded it to itterate through notes and pnotes as well, and started making it object oriented so it can either default to the handler and make Perl*Handler phase choices for you, or you can call any of the dump routines on the fly... do these sound like value added features? Should they be incorporated into DumpHeaders or do the warrant their own module? I renamed the one I am working on Apache::DebugLog... Major feature is that it can be configured to only dump traffic from certain IP addresses. this looks like a nice feature - I'll have to look at it some more... --Geoff - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
ANNOUNCE: Apache::GTopLimit
Well, this module has been around for awhile, since mod_perl-1.22 is distributed as a separate package. Please allow a few hours before CPAN mirrors will get their copy before trying to download it. The uploaded file Apache-GTopLimit-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/S/ST/STAS/Apache-GTopLimit-0.01.tar.gz size: 4907 bytes md5: d66923334cc6ff3acb41ed581ac38449 - NAME Apache::GTopLimit - Limit Apache httpd processes SYNOPSIS This module allows you to kill off Apache httpd processes if they grow too large or have too little of shared memory. You can choose to set up the process size limiter to check the process size on every request: # in your startup.pl: use Apache::GTopLimit; # Control the life based on memory size # in KB, so this is 10MB $Apache::GTopLimit::MAX_PROCESS_SIZE = 1; # Control the life based on Shared memory size # in KB, so this is 4MB $Apache::GTopLimit::MIN_PROCESS_SHARED_SIZE = 4000; # watch what happens $Apache::GTopLimit::DEBUG = 1; # in your httpd.conf: PerlFixupHandler Apache::GTopLimit # you can set this up as any Perl*Handler that handles # part of the request, even the LogHandler will do. Or you can just check those requests that are likely to get big or unshared. This way of checking is also easier for those who are mostly just running Apache::Registry scripts: # in your CGI: use Apache::GTopLimit; # Max Process Size in KB Apache::GTopLimit-set_max_size(1); and/or use Apache::GTopLimit; # Min Shared process Size in KB Apache::GTopLimit-set_min_shared_size(4000); Since accessing the process info might add a little overhead, you may want to only check the process size every N times. To do so, put this in your startup.pl or CGI: $Apache::GTopLimit::CHECK_EVERY_N_REQUESTS = 2; This will only check the process size every other time the process size checker is called. Note: The MAX_PROCESS_SIZE and MIN_PROCESS_SHARED_SIZE are standalone, and each will be checked if only set. So if you set both -- the process can be killed if it grows beyond the limit or its shared memory goes below the limit. DESCRIPTION This module will run on platforms supported by GTop.pm a Perl interface to libgtop (which in turn needs libgtop : See http://home-of-linux.org/gnome/libgtop/ ). This module was written in response to questions on the mod_perl mailing list on how to tell the httpd process to exit if: * its memory size goes beyond a specified limit * its shared memory size goes below a specified limit Limiting memory size Actually there are two big reasons your httpd children will grow. First, it could have a bug that causes the process to increase in size dramatically, until your system starts swapping. Second, your process just does stuff that requires a lot of memory, and the more different kinds of requests your server handles, the larger the httpd processes grow over time. This module will not really help you with the first problem. For that you should probably look into Apache::Resource or some other means of setting a limit on the data size of your program. BSD-ish systems have setrlimit() which will croak your memory gobbling processes. However it is a little violent, terminating your process in mid-request. This module attempts to solve the second situation where your process slowly grows over time. The idea is to check the memory usage after every request, and if it exceeds a threshold, exit gracefully. By using this module, you should be able to discontinue using the Apache configuration directive MaxRequestsPerChild, although for some folks, using both in combination does the job. Personally, I just use the technique shown in this module and set my MaxRequestsPerChild value to 6000. Limiting shared memory size We want the reverse the above limit for a shared memory limitation and kill the process when its hs too little of shared memory. When the same memory page is being shared between many processes, you need less physical memory relative to the case where the each process will have its own copy of the memory page. If your OS supports shared memory you will get a great benefit when you deploy this feature. With mod_perl you enable it by preloading the modules at the server startup. When you do that, each child uses the same memory page as the parent does, after it forks. The memory pages get unshared when a child modifies the page and it can no longer be shared, that's when the page is being copied to the child's domain and then modified
Re: [PATCH] in memory $Application object for Apache::ASP
On Mar 29, [EMAIL PROTECTED] hacked the bitstream to say...
Joshua Joel Reed wrote:
Joshua
Joshua this may be a dumb patch to Apache::ASP (at least it is my first).
Joshua
Joshua Rationale:
Joshua
Joshua i have the following issues with the current implementation of $Application
Joshua
Joshua 1. everything you store in $Application-{foo} must be
Joshua serializable my MLDBM. (right?) i have SWIG'd c++ classes for
Joshua which this will not work.
Joshua
Joshua 2. limitation #1 seems to limit Apache:ASP's usefulness as a
Joshua cross-platform solution to ActivePerl/IIS/ASP scripts you
Joshua want to move to linux, etc. i want to do this - not sure if
Joshua this is really a key thing for joshua though...
Joshua ...
Joshua
Joshua What you are talking about is just a global that you access
Joshua in your scripts. You could declare this in your global.asa
Joshua with
Joshua
Joshua use vars qw($Application2);
Joshua
Joshua Then just use it like $Application2-{key} = $value;
Joshua
Joshua I use this kind of in process data caching all the time,
Joshua and you will see that Apache::DBI does something similar.
only then i don't have API consistency from NT/iis/asp... maybe
this is a unreasonable goal of mine... :(
Joshua
Joshua What you don't get here is interprocess communication
Joshua which is what the use of $Application is geared for, that
Joshua the data is stored is some process neutral location, so
Joshua web requests may access the data independent of the httpd
Joshua process they are coming from.
Joshua
yes this is the killer with making my stuff work for both iis/asp modperl.
do you have any suggestions for an api consistent solution? maybe i could
hack up something where $Application data was obtainable thru IPC? the
killer is the serialization requirement as i'm dealing with perl encapsulated
c++ objects...
thanks for your feedback,
jr
--
Joel W. Reed http://ruby.ddiworld.com/jreed
---A few cans short of a six pack, Six short.---
Re: [PATCH] in memory $Application object for Apache::ASP
On Mar 29, [EMAIL PROTECTED] hacked the bitstream to say... modperl Joshua What you don't get here is interprocess communication modperl Joshua which is what the use of $Application is geared for, that modperl Joshua the data is stored is some process neutral location, so modperl Joshua web requests may access the data independent of the httpd modperl Joshua process they are coming from. modperl Joshua modperl modperl yes this is the killer with making my stuff work for both iis/asp modperl. modperl do you have any suggestions for an api consistent solution? maybe i could modperl hack up something where $Application data was obtainable thru IPC? the modperl killer is the serialization requirement as i'm dealing with perl encapsulated modperl c++ objects... sorry to respond to myself but i just realized a got momentarily confused. what i would love to have is api consistent (w/ IIS/ASP) means of all scripts served by apache process "foo" to be able to access the $Application data and that this data doesn't have a must-be-serializable requirement. Apache::ASP currently provides $Application data thru MLDBM serialization that is available to ALL apache processes. i could imagine at least some people porting IIS/ASP/ActivePerlScript applications to apache/mod_perl would appreciate someway to do what i'm trying to do. under IIS lots of folks make COM objects, stuff them in $Application and all the IIS threads use the $App data just fine. when these folks port to apache/linux use must drop COM (thus i'm wrapping straight C++ libraries into Perl objects with SWIG), but i still need this can't-require serialization-support for $Application data requirement and would gladly accept each process having its own $Application data. what about a configuration option that was something like... PerlSetVar AppDataPerProcess (0|1) jr -- Joel W. Reed http://ruby.ddiworld.com/jreed "This is a job for.. AACK! WAAUGHHH!! ...someone else." - Calvin
Re: Problem re-directing STDOUT in system() calls
"Andrei A. Voropaev" wrote: See the guide. Under modperl the output from system will not go to the user unless your perl was compiled with sfio. The reason for that I guess is that under modperl STDOUT is tied to a package, while system commands expect file descriptor. The easiest way to overcome it is to use `` (backtics) and capture all output into variable and then print it out. Andrei The guide actually says: 3.5.5 Output from system calls Output of system(), exec(), and open(PIPE,"|program") calls will not be sent to the browser unless your Perl was configured with sfio. which is fair enough, but does it explain the problem I've got? It DOES explain why the following script prints the output of IPCONFIG in the browser when running under Apache and doesn't when running under Apache + mod_perl: $| = 1; print "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe"; print "The system() call exited with status $status.\n"; but that isn't my problem. How does it explain why the following works under Apache 1.3.6 + mod_perl and not under Apache 1.3.12 + mod_perl: print "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe D:\\Temp\\ip.txt"; print "The system() call exited with status $status.\n"; ? I'm not trying to get the output of the system() call into the browser - I want to re-direct it to a file - and the difference between the one which works and the one which doesn't work is not mod_perl: it's the Apache version! Am I also correct in thinking that configuring Perl with sfio is only an option on Unix (which, BTW, doesn't have my problem anyway!)? Help! Steve Hay
RE: [new module] proposal Apache::DebugHeaders
On Wed, 29 Mar 2000, Geoffrey Young wrote: actually, http://perl.apache.org/src/apache-modlist.html recommends h2xs -AX -n Apache::YourPackageName what's the -C option - it isn't in my perldoc h2xs? It was supposed to be -c, shoot the typist :) Not really relevant with -X, but I always use it anyway, because I prefer to not have any of the crappy cruft that h2xs gives you by default. (I use -P too quite often). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [OT slightly] mod_perl developers (do they exist?)
Well, I don't know if the rest of you actually exist, but I do, and I'm looking for a job!
porting DBI to Apache::DBI
Haloo
I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
Apache::Registry
for the most efficient:
if my normal DBI CGI is:
use strict;
use DBI;
my $dbh=DBI-connect("database","login","password","mysql");
..
$dbh-disconnect;
=
when port to Apache::DBI should I modify it as
1:
use strict;
use DBI;
use vars qw($dbh);
$dbh=DBI-connect("database","login","password","mysql");
$dbh-disconnect;
===
or
2:
use strict;
use DBI;
use vars qw($dbh);
$dbh ||=DBI-connect("database","login","password","mysql");
.
$dbh-disconnect;
or
3:
need not to change any thing?
__
Get Your Private, Free Email at http://www.hotmail.com
RE: perl 5.6/mod_perl 1.22/apache 1.3.12
Success! after 4 days. 3 full pages of warnings during the 1.22 Makefile, I guess I never tried installing mod_perl after this, I kept trying 1.21 with 5.6 and 1.3.12, a, moron. Thanks Doug for taking the blinders off me. Charles -Original Message- From: Doug MacEachern [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 29, 2000 12:27 AM To: Charles Day Cc: '[EMAIL PROTECTED]' Subject: Re: perl 5.6/mod_perl 1.22/apache 1.3.12 On Mon, 27 Mar 2000, Charles Day wrote: Just spent half the day trying marry these 3. mod_perl doesn't build. DSO/apxs errors as described by others. these errors were just warnings, try cvs if you want to get rid of them. did you have other problems too?
Re: [PATCH 5.6.0] local $SIG{FOO} restoration
In [EMAIL PROTECTED],
Doug MacEachern writes:
:when 'local $SIG{ALRM} = sub {...}' goes out of scope, magic_setsig() sets
:the SIGALRM handler to SIG_DFL, rather than the original handler. this
:causes quite a bit of trouble running inside of apache, since 'local
:$SIG{ALRM}' unhooks the apache SIGALRM handler for the life of that
:proccess.
:the original handler is already fetched by magic_getsig(), this patch
:saves that pointer so it can be restored in magic_setsig().
[snip]
I believe that this (or take2) might cause a problem for code like:
sub handler { print "sig handled" }
my $handlesub = "handler";
[... something reads $handlesub in numeric context ...]
$SIG{ALRM} = $handlesub;
I'm not sure how big a concern that should be, if it is true.
Hugo
Re: [PATCH] hack for $App obj in memory take 2 (config opt)
Joel Reed wrote: i'm not sure if anyone will ever find this useful but this makes $Application a per-process global var if you prefer that. this is probably terribly coded but it works for what i need (i'm definitely not a perl guru). please suggest improvement if you can ;) need PerlSetVar AppDataPerProcess 1 If you set AllowApplicationState to 0, then the system will not define $Application, and you are free to use it then for a per-process global. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: [PATCH] in memory $Application object for Apache::ASP
Joel Reed wrote: modperl yes this is the killer with making my stuff work for both iis/asp modperl. modperl do you have any suggestions for an api consistent solution? maybe i could modperl hack up something where $Application data was obtainable thru IPC? the modperl killer is the serialization requirement as i'm dealing with perl encapsulated modperl c++ objects... sorry to respond to myself but i just realized a got momentarily confused. what i would love to have is api consistent (w/ IIS/ASP) means of all scripts served by apache process "foo" to be able to access the $Application data and that this data doesn't have a must-be-serializable requirement. Apache::ASP currently provides To really have a consistent API, Apache + mod_perl will have to go multi-threaded. Or you can turn off $Application with AllowApplicationState 0 as I suggested in the last mail, and run your Apache web server with MaxClients 1, and put a proxy in front of it. I wouldn't advise it, but its a possibility. Note that if you do go the route of disabling $Application and such, you will lose access to the events Application_OnStart Application_OnEnd -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
On Wed, 29 Mar 2000, Jerome MOUREAUX wrote:
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve service
name
(DBD: login failed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
^^
my $dbh = DBI-connect( 'DBI:Oracle:INDICATORS', 'indic', ',
^^
Well, which is it? indicators or INDICATORS? Case may be important, use
the same case as the service name definition in tnsnames.ora.
-jwb
Re: porting DBI to Apache::DBI
"James Array" [EMAIL PROTECTED] wrote:
Haloo
I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
Apache::Registry
for the most efficient:
if my normal DBI CGI is:
use strict;
use DBI;
my $dbh=DBI-connect("database","login","password","mysql");
..
$dbh-disconnect;
=
when port to Apache::DBI should I modify it as
1:
use strict;
use DBI;
use vars qw($dbh);
$dbh=DBI-connect("database","login","password","mysql");
$dbh-disconnect;
This would be a good try. If Apache::DBI is loaded first, it will cache
connections and create a new one only if there isn't an existing connection
for the particular combination of connection arguments. More details should
available in the Apache::DBI perldoc.
You definitely want to go with a `use vars' for $dbh if it can't be localized
to a subroutine. But then, I haven't done Apache::Registry scripts for so
long, I can't remember for sure (most of my code now is modules). You might
want to check out the mod_perl Guide on that one.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
SUCCESS: SGI Irix freeware perl + apache 1.3.12, dynamicallylinked.
Posting in the hopes it helps others out. Caveat empor thou, i've only tested bare functionality nothing more so far! After various headpounding exercises trying to get mod_perl integrated into the Irix freeware perl5.00503 and freeware apache (1.3.9), I've found the magic incantation that made rld stop bitching about unresolvable symbols. A tip o' the wizard's hat to Alan Burlison for the discussion[1] in the apache+mod_perl+solaris thread that gave me the lead on the incantation. Like Solaris, Irix has a way to preload or override library linkage, it's just called a different name -- _RLD_LIST: tcsh env _RLD_LIST=/usr/freeware/apache/libexec/libperl.so:\ /usr/freeware/lib/perl5/5.00503/irix-o32/CORE/libperl.so:DEFAULT\ /usr/freeware/apache/bin/httpd Alert readers will note that I mention apache 1.3.12 in the subject line, yet allude to the freeware 1.3.9 apache. I need o32 (as opposed to n32, the default 32bit code) binaries to link against the Oracle libs I'm using for DBI::Oracle, so I simply built installed 1.3.12 using the freeware config. I can't see any reason why the use of _RLD_LIST couldn't be used to create a mod_perl against 'stock' irix freeware apache perl, which are compiled n32, thou. (if anyone has leads on *supported* n32 Oracle libs, I'd love to hear about it. Recompiling umpteen bits -o32 gets tiring.) [ and sorry, i'm not on the modperl mailing list, so mail direct if you're looking for a response from me. ] [1] [EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/shingchaxtwax/[EMAIL PROTECTED] cheers, --Chan --- _ -- Chan Wilson_____ (_) Principal Systems Administrator cwilson at sgi.com /',__) /'_ `\| | Enterprise Network Services +41-32-843-3760 \__, \( (_) || | Cortaillod, Switzerland Vnet 476-3760(/`\__ |(_) ( )_) | \___/'
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
The ORACLE_HOME ___environment___ variable is set where? I see no indication
of it being set in any of your examples or config.
I do see PerlSetVar setting it-- don't confuse that with the environment!
PerlSetVar is a specific way to set variables so mod_perl can read them via
the dir_config() method.
I usually set my ORACLE_HOME inside my startup.pl so all the Apache children
can definitely find it:
$ENV{ORACLE_HOME}='/disc1/sherpa/oracle';
You might also be able to use Apache's SetEnv directive, see the following
URL for details and possible restrictions:
http://www.apache.org/docs/mod/mod_env.html#setenv
And finally, you should double check your case in your DSN during your
connect(). Oracle SIDs might be case sensitive and thus not finding the
proper SID. (I always have SIDs that are all capital letters, so I couldn't
tell you for sure.)
Hope this helps.
-d.
Jerome MOUREAUX said...
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve service
name
(DBD: login failed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
The ORACLE_HOME is well set ! I first tried to use Apache::DBI but i get
this error
so I go back to DBI only but it's exactly the same error.
My scripts run well if I launch it from the command line.
Here is extracts of my httpd.conf
# Additionnal directory (for indicators)
Alias /indicators2/perl "/disc1/sherpa_a/indicators2/perl"
Location /indicators2/perl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
/Location
at the end:
PerlSetEnv ORACLE_HOME /disc1/sherpa/oracle
PerlRequire conf/startup.pl
PerlFreshRestartOn
Here is the startup.pl
#!/usr/bin/perl
# Commonly used modules
use Apache::Registry ();
use Apache::Constants ();
use CGI ();
#use Apache::DBI ();
#$Apache::DBI::DEBUG=2;
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
{ AutoCommit = 0, RaiseError = 1, PrintError = 0 } )
or die $DBI::errstr;
1;
And finally my test file:
#!/usr/bin/perl
use DBI;
my $dbh = DBI-connect( 'DBI:Oracle:INDICATORS', 'indic', ',
{ AutoCommit = 0, RaiseError = 0, PrintError = 1 } )
or die $DBI::errstr;
$dbh-disconnect;
Thanks in advance
Jerome
--
David S. Kenzik
[EMAIL PROTECTED] - http://kenzik.com
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
Thanks Jeffrey but:
- the tnsname.ora is OK as tnsping works fine as well as the same script run
from the command line.
- the case is only important for Oracle in the string dbi:Oracle:SID
(the line in startup.pl in commented it was just a previous try)
I'm really running out of idea about this problem. I never had any problem
with DBI
in other command line perl scripts as well as in traditionnal perl CGI
scripts so I
think there is something linked to Registry ???
Regards
Jerome
At 10:33 AM 29-03-00 -0800, Jeffrey W. Baker wrote:
On Wed, 29 Mar 2000, Jerome MOUREAUX wrote:
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve
service
name
(DBD: login failed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
^^
my $dbh = DBI-connect( 'DBI:Oracle:INDICATORS', 'indic', ',
^^
Well, which is it? indicators or INDICATORS? Case may be important, use
the same case as the service name definition in tnsnames.ora.
-jwb
SOCK_RAW
Hi, I must use SOCK_RAW within a mod-perl module to implement with ip-tunneling dynamic load balancing on a cluster. Unfortunately i think that this is impossible whith Apache 1.3's API because of Apache's core handles connections (Apache modules can use SOCK_STREAM after a client connection, but they can't do connections with clients and handle a TCP stream or an IP datagram). Could someone confirm this? Can Apache 2's API handle SOCK_RAW ? Thanks, Inaki ~~~ .~.Iñaki Fernández Villanueva DEBIAN/GNU /V\[EMAIL PROTECTED] [EMAIL PROTECTED] // \\ Linux registered user #93164 SLINK 2.1/( )\ Student in Computer Engineering ^^-^^ University of San Sebastian (Spain) www.debian.org ~~~
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
David,
The ORACLE_HOME is set in the httpd.conf with a PerlSetEnv directive.
(it appears in the extract I sent). (I've checked that is OK in the scripts by
printing out $ENV{ORACLE_HOME} )
The SID is not case sensitive (I tried some combination when I was trying to
figure out what happen) otherwise it would mean that SID are insensitive when
running the script from command line and sensitive when running from Apache !
Thanks for you help
Regards
Jerome
At 03:43 PM 29-03-00 -0500, David S . Kenzik wrote:
The ORACLE_HOME ___environment___ variable is set where? I see no indication
of it being set in any of your examples or config.
I do see PerlSetVar setting it-- don't confuse that with the environment!
PerlSetVar is a specific way to set variables so mod_perl can read them via
the dir_config() method.
I usually set my ORACLE_HOME inside my startup.pl so all the Apache children
can definitely find it:
$ENV{ORACLE_HOME}='/disc1/sherpa/oracle';
You might also be able to use Apache's SetEnv directive, see the following
URL for details and possible restrictions:
http://www.apache.org/docs/mod/mod_env.html#setenv
And finally, you should double check your case in your DSN during your
connect(). Oracle SIDs might be case sensitive and thus not finding the
proper SID. (I always have SIDs that are all capital letters, so I couldn't
tell you for sure.)
Hope this helps.
-d.
Jerome MOUREAUX said...
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve
service
name
(DBD: login failed) at
/disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
The ORACLE_HOME is well set ! I first tried to use Apache::DBI but i get
this error
so I go back to DBI only but it's exactly the same error.
My scripts run well if I launch it from the command line.
Here is extracts of my httpd.conf
# Additionnal directory (for indicators)
Alias /indicators2/perl "/disc1/sherpa_a/indicators2/perl"
Location /indicators2/perl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
/Location
at the end:
PerlSetEnv ORACLE_HOME /disc1/sherpa/oracle
PerlRequire conf/startup.pl
PerlFreshRestartOn
Here is the startup.pl
#!/usr/bin/perl
# Commonly used modules
use Apache::Registry ();
use Apache::Constants ();
use CGI ();
#use Apache::DBI ();
#$Apache::DBI::DEBUG=2;
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
{ AutoCommit = 0, RaiseError = 1, PrintError = 0 } )
or die $DBI::errstr;
1;
And finally my test file:
#!/usr/bin/perl
use DBI;
my $dbh = DBI-connect( 'DBI:Oracle:INDICATORS', 'indic', ',
{ AutoCommit = 0, RaiseError = 0, PrintError = 1 } )
or die $DBI::errstr;
$dbh-disconnect;
Thanks in advance
Jerome
--
David S. Kenzik
[EMAIL PROTECTED] - http://kenzik.com
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
My mistake, Jerome.
PerlSetVar != PerlSetEnv
I read that as PerlSetVar. Sorry to confuse the issue.
I hope it's a simple permissions problem.
Good luck!
David S . Kenzik said...
Jerome MOUREAUX said...
David,
The ORACLE_HOME is set in the httpd.conf with a PerlSetEnv directive.
(it appears in the extract I sent). (I've checked that is OK in the scripts by
printing out $ENV{ORACLE_HOME} )
Well I can pretty much guarantee you that the ORACLE_HOME environment is not
being set by PerlSetVar. That is simply not the function of PerlSetVar.
You must have it set globally in /etc/profile or similar if you're able to
print it. And if you are indeed able to print it, then it not being set is
not your problem.
Just to humour me, please set it in your startup.pl like my example shows,
and remove the PerlSetVar line in your httpd.conf. Try again. If the problem
persists, it's something else. Maybe permissions...
Does the webserver user have rights to look at tnsnames.ora and other
items inside /disc1/sherpa/oracle? To verify, su into your webserver user
and attempt to run your script from the command line.
The SID is not case sensitive (I tried some combination when I was trying to
figure out what happen) otherwise it would mean that SID are insensitive when
running the script from command line and sensitive when running from Apache !
OK. It's not case sensitive. I've learned something new today, and verified
by reconfiguring my tnsnames.ora.
Good luck.
At 03:43 PM 29-03-00 -0500, David S . Kenzik wrote:
The ORACLE_HOME ___environment___ variable is set where? I see no indication
of it being set in any of your examples or config.
I do see PerlSetVar setting it-- don't confuse that with the environment!
PerlSetVar is a specific way to set variables so mod_perl can read them via
the dir_config() method.
I usually set my ORACLE_HOME inside my startup.pl so all the Apache children
can definitely find it:
$ENV{ORACLE_HOME}='/disc1/sherpa/oracle';
You might also be able to use Apache's SetEnv directive, see the following
URL for details and possible restrictions:
http://www.apache.org/docs/mod/mod_env.html#setenv
And finally, you should double check your case in your DSN during your
connect(). Oracle SIDs might be case sensitive and thus not finding the
proper SID. (I always have SIDs that are all capital letters, so I couldn't
tell you for sure.)
Hope this helps.
-d.
Jerome MOUREAUX said...
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve
service
name
(DBD: login failed) at
/disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
The ORACLE_HOME is well set ! I first tried to use Apache::DBI but i get
this error
so I go back to DBI only but it's exactly the same error.
My scripts run well if I launch it from the command line.
Here is extracts of my httpd.conf
# Additionnal directory (for indicators)
Alias /indicators2/perl "/disc1/sherpa_a/indicators2/perl"
Location /indicators2/perl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
/Location
at the end:
PerlSetEnv ORACLE_HOME /disc1/sherpa/oracle
PerlRequire conf/startup.pl
PerlFreshRestartOn
Here is the startup.pl
#!/usr/bin/perl
# Commonly used modules
use Apache::Registry ();
use Apache::Constants ();
use CGI ();
#use Apache::DBI ();
#$Apache::DBI::DEBUG=2;
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
{ AutoCommit = 0, RaiseError = 1, PrintError = 0 } )
or die $DBI::errstr;
1;
And finally my test file:
#!/usr/bin/perl
use DBI;
my $dbh = DBI-connect( 'DBI:Oracle:INDICATORS', 'indic', ',
{ AutoCommit = 0, RaiseError = 0, PrintError = 1 } )
or die $DBI::errstr;
$dbh-disconnect;
Thanks in advance
Jerome
--
David S. Kenzik
[EMAIL PROTECTED] - http://kenzik.com
--
David S. Kenzik
[EMAIL PROTECTED] - http://kenzik.com
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
On Wed, 29 Mar 2000, Jerome MOUREAUX wrote: Alias /indicators2/perl "/disc1/sherpa_a/indicators2/perl" [...] PerlSetEnv ORACLE_HOME /disc1/sherpa/oracle Do you really have a /disc1/sherpa directory and a /disc1/sherpa_a directory? - Perrin
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
A final effort... From the command line it works. Perhaps your ORACLE_USERID,
etc. is already set?
Within your Registry script, that's probably not the case unless you've
explicitly told it otherwise.
So let's change your DSN around a bit:
my $dbh = DBI-connect('dbi:Oracle:', 'indic/xxx@INDICATORS', '',
{ AutoCommit = 0, RaiseError = 0, PrintError = 1 } ) or die $DBI::errstr;
I don't use the same format of the connect string that you are showing in
your example below (I use the format above.) In fact, I vaguely remember
encountering a similar problem when using a 'typical' connect string with
other DB's.
I'm hoping that something in your current environment is set allowing that
format to work, when in actuality it's the improper way.
Let's see if this works. If not, I'm out of ideas. :-(
Good luck!
-d.
David S . Kenzik said...
My mistake, Jerome.
PerlSetVar != PerlSetEnv
I read that as PerlSetVar. Sorry to confuse the issue.
I hope it's a simple permissions problem.
Good luck!
David S . Kenzik said...
Jerome MOUREAUX said...
David,
The ORACLE_HOME is set in the httpd.conf with a PerlSetEnv directive.
(it appears in the extract I sent). (I've checked that is OK in the scripts by
printing out $ENV{ORACLE_HOME} )
Well I can pretty much guarantee you that the ORACLE_HOME environment is not
being set by PerlSetVar. That is simply not the function of PerlSetVar.
You must have it set globally in /etc/profile or similar if you're able to
print it. And if you are indeed able to print it, then it not being set is
not your problem.
Just to humour me, please set it in your startup.pl like my example shows,
and remove the PerlSetVar line in your httpd.conf. Try again. If the problem
persists, it's something else. Maybe permissions...
Does the webserver user have rights to look at tnsnames.ora and other
items inside /disc1/sherpa/oracle? To verify, su into your webserver user
and attempt to run your script from the command line.
The SID is not case sensitive (I tried some combination when I was trying to
figure out what happen) otherwise it would mean that SID are insensitive when
running the script from command line and sensitive when running from Apache !
OK. It's not case sensitive. I've learned something new today, and verified
by reconfiguring my tnsnames.ora.
Good luck.
At 03:43 PM 29-03-00 -0500, David S . Kenzik wrote:
The ORACLE_HOME ___environment___ variable is set where? I see no indication
of it being set in any of your examples or config.
I do see PerlSetVar setting it-- don't confuse that with the environment!
PerlSetVar is a specific way to set variables so mod_perl can read them via
the dir_config() method.
I usually set my ORACLE_HOME inside my startup.pl so all the Apache children
can definitely find it:
$ENV{ORACLE_HOME}='/disc1/sherpa/oracle';
You might also be able to use Apache's SetEnv directive, see the following
URL for details and possible restrictions:
http://www.apache.org/docs/mod/mod_env.html#setenv
And finally, you should double check your case in your DSN during your
connect(). Oracle SIDs might be case sensitive and thus not finding the
proper SID. (I always have SIDs that are all capital letters, so I couldn't
tell you for sure.)
Hope this helps.
-d.
Jerome MOUREAUX said...
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve
service
name
(DBD: login failed) at
/disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
The ORACLE_HOME is well set ! I first tried to use Apache::DBI but i get
this error
so I go back to DBI only but it's exactly the same error.
My scripts run well if I launch it from the command line.
Here is extracts of my httpd.conf
# Additionnal directory (for indicators)
Alias /indicators2/perl "/disc1/sherpa_a/indicators2/perl"
Location /indicators2/perl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
/Location
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
Write a small registry script to print %ENV and confirm ORACLE_HOME is set to /disc1/sherpa/oracle. In your shell, # cat eof/tmp/test.sh \$ORACLE_HOME/bin/tnsping YourTNSAlias eof # su - nobody -c 'env ORACLE_HOME=/path/to/oracle sh /tmp/test.sh' John [EMAIL PROTECTED]
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
On Wed, 29 Mar 2000, Jerome MOUREAUX wrote: My scripts run well if I launch it from the command line. Have you tried running them from the command line as the user who the webserver runs as? There may be something in your user environment that allows them to work which is not set up for this other user. - Perrin
Re: ORA-12154: TNS:could not resolve service name with DBIunder Apache
Hi, Jerome.
I know you said that your tnsnames.ora is okay because tnsping works.
However, the ORACLE error in the subject line indicates that ORACLE is
choking on whatever database name it's receiving from perl. Try
tnsping'ing or connecting to a database that you know doesn't exist in
your tnsnames.ora. You'll see the same error.
Find out exactly what database name is being passed to Oracle and I
think you'll be able to resolve your problem.
Tom
Jerome MOUREAUX said...
Hi All,
I experience a trouble with Perl script using DBI running under Mod_perl
and Registry
If you have an idea from where the problem may come
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve
service
name
(DBD: login failed) at
/disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
The ORACLE_HOME is well set ! I first tried to use Apache::DBI but i get
this error
so I go back to DBI only but it's exactly the same error.
My scripts run well if I launch it from the command line.
Here is extracts of my httpd.conf
# Additionnal directory (for indicators)
Alias /indicators2/perl "/disc1/sherpa_a/indicators2/perl"
Location /indicators2/perl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
/Location
at the end:
PerlSetEnv ORACLE_HOME /disc1/sherpa/oracle
PerlRequire conf/startup.pl
PerlFreshRestartOn
Here is the startup.pl
#!/usr/bin/perl
# Commonly used modules
use Apache::Registry ();
use Apache::Constants ();
use CGI ();
#use Apache::DBI ();
#$Apache::DBI::DEBUG=2;
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
{ AutoCommit = 0, RaiseError = 1, PrintError = 0 } )
or die $DBI::errstr;
1;
And finally my test file:
#!/usr/bin/perl
use DBI;
my $dbh = DBI-connect( 'DBI:Oracle:INDICATORS', 'indic', ',
{ AutoCommit = 0, RaiseError = 0, PrintError = 1 } )
or die $DBI::errstr;
$dbh-disconnect;
Thanks in advance
Jerome
SOCK_RAW
Hi, I must use SOCK_RAW within a mod-perl module to implement with ip-tunneling dynamic load balancing on a cluster. Unfortunately i think that this is impossible whith Apache 1.3's API because of Apache's core handles connections (Apache modules can use SOCK_STREAM after a client connection, but they can't do connections with clients and handle a TCP stream or an IP datagram). Could someone confirm this? Can Apache 2's API handle SOCK_RAW ? Thanks, Inaki ~~~ .~.Iñaki Fernández Villanueva DEBIAN/GNU /V\[EMAIL PROTECTED] // \\ Linux registered user #93164 SLINK 2.1/( )\ Student in Computer Engineering ^^-^^ University of San Sebastian (Spain) www.debian.org ~~~
POST data ending up in access_log
i sometimes have problems sending POST data. most of the time, everything works fine. however, sometimes, i see something like the following in my access_log: --- snip 8--- ... "GET /transact HTTP/1.1" 200 3412 ... "POST /transact HTTP/1.1" 200 3412 ... "key1=val1key2=val2key3=val3POST /transact HTTP/1.1" 302 293 ... "GET /transact HTTP/1.1" 200 3412 ... "POST /transact HTTP/1.1" 302 293 --- snip 8--- the middle line is the weird one. sometimes my POSTed data seems to end up there in the log instead of being sent to the client. has anyone seen this sort of behavior before? any ideas on possible causes? come to think of it, i believe i've seen this happen occasionally with GET requests as well. i'm running: apache 1.3.9 modperl 1.21 thanks! -sanjay
Re: ORA-12154: TNS:could not resolve service name with DBI under Apache
Jerome MOUREAUX [EMAIL PROTECTED] writes:
David,
The ORACLE_HOME is set in the httpd.conf with a PerlSetEnv directive.
(it appears in the extract I sent). (I've checked that is OK in the scripts by
printing out $ENV{ORACLE_HOME} )
The SID is not case sensitive (I tried some combination when I was trying to
figure out what happen) otherwise it would mean that SID are insensitive when
running the script from command line and sensitive when running from Apache !
[...]
Here is the error :
DBI-connect failed: ORA-12154: TNS:could not resolve service name (DBD:
login f
ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
[Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve
service
name
(DBD: login failed) at
/disc1/sherpa_a/indicators2/perl/activity/toto.pl
line 5
[...]
#$Apache::DBI::DEBUG=2;
#Apache::DBI-connect_on_init("dbi:Oracle:indicators", "indic", "",
{ AutoCommit = 0, RaiseError = 1, PrintError = 0 } )
or die $DBI::errstr;
1;
Have you tried something like:
Apache::DBI-connect_on_init("dbi:Oracle:server=indicators;database=XXX",
"indic", "", { AutoCommit = 0, RaiseError = 1, PrintError = 0 } )
or die $DBI::errstr;
explicitly supplying the server and avoiding the `use XXX' on the
first connect? Works with Sybase, anyway.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Alan E. DerhaagConsultant from Interactive Business Systems
phone: 206-336-2972 Consultant to N2H2
email: [EMAIL PROTECTED] [EMAIL PROTECTED]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
getting mod_perl working
I've been trying to get ePerl installed on a redhat system, and I seem to have narrowed it down to a problem with mod_perl and/or apache. Whenever I add a PerlModule statement to httpd.conf and try to restart httpd, it won't run. Doesn't give me any error messages--it just refuses to work. I've tried it with both 'PerlModule Apache::Status' and 'PerlModule Apache::ePerl', and I've also tried it on two different systems--both running apache 1.3.9 and mod_perl 1.21, freshly installed. Any idea what I could be doing wrong? Joel Young . . . .::.: * . . .We're all mad here. [EMAIL PROTECTED] * ** ' 'I'm mad. http://lo.res.cmu.edu/reverie/ ' You're mad.
Re: getting mod_perl working
Anything in the error_log? cliff rayman genwax.com Quadrilateral I was wrote: I've been trying to get ePerl installed on a redhat system, and I seem to have narrowed it down to a problem with mod_perl and/or apache. Whenever I add a PerlModule statement to httpd.conf and try to restart httpd, it won't run. Doesn't give me any error messages--it just refuses to work. I've tried it with both 'PerlModule Apache::Status' and 'PerlModule Apache::ePerl', and I've also tried it on two different systems--both running apache 1.3.9 and mod_perl 1.21, freshly installed. Any idea what I could be doing wrong? Joel Young . . . .::.: * . . .We're all mad here. [EMAIL PROTECTED] * ** ' 'I'm mad. http://lo.res.cmu.edu/reverie/ ' You're mad.
getting Image::Magick
I am trying to get Image::Magick compiled and installed. I am using CPAN and am getting this error: --- AutoSplitting blib/lib/Image/Magick.pm (blib/lib/auto/Image/Magick) /usr/local/bin/perl -I/usr/local/lib/perl5/5.6.0/i686-linux -I/usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/5.6.0/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.6.0/ExtUtils/typemap Magick.xs Magick.xsc mv Magick.xsc Magick.c cc -c -I.. -I/usr/local/include -I/usr/openwin/include -I/usr/openwin/include/X11 -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"4.28\" -DXS_VERSION=\"4.28\" -fpic -I/usr/local/lib/perl5/5.6.0/i686-linux/CORE Magick.c In file included from /usr/local/include/magick/magick.h:45, from Magick.xs:78: /usr/include/assert.h:79: warning: `assert' redefined /usr/local/lib/perl5/5.6.0/i686-linux/CORE/perl.h:2054: warning: this is the location of the previous definition Magick.xs:79: magick/defines.h: No such file or directory make: *** [Magick.o] Error 1 /usr/bin/make -- NOT OK Running make test Oops, make had returned bad status Running make install Oops, make had returned bad status --- Has anyone seen this error before? Any thoughts on how to fix it? Sam Carleton
File uploading?
Hello Everyone, I've been beating my head up against file uploading via the browser, in mod_perl. The example in the Eagle book doesn't seem to be working for me. This is the latest error I'm getting: [Wed Mar 29 20:36:07 2000] [error] Can't locate object method "new" via package "Apache::Request" at /usr/local/apache/mod_perl/Upload.pm line 6. I was wondering if someone could point me to a quick and dirty Upload module so I can figure out what is wrong. P.S. Apache::Request is installed, but doesn't seem to contain a new subroutine. --- Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org ---
Re: performance mongers: since when is using CGI.pm or Apache::Registrydishonorable?
CGI.pm is a great piece of code, but its very monolithic. Lincoln/Doug's
libapreq module is probably much faster (I have never run benchmarks) than
CGI.pm, so it makes sense for those who like the Q-param type interface
(I do) for working with CGI environment variables, but don't need all the
handy html and cookie functions/methods the CGI.pm provides.
A lot of mod_perl shops have aready developed their own templating scheme,
or page object model, or are using one of Mason, ASP, embperl etc . . .
and don't have a lot of use for 85% of CGI.pm's library routines.
Again, there are c based modules now for HTTP utils and cookies as well,
which provide more speed.
The reason many prefer native Apache methods over wrapped cgi scripts is
not just speed, but coding style and maturity. Writing modules and setting
up objects requires more discipline that writing quick scripts and relying
on magic to reset your environment for the next execution run. I have
applications that now run as deep as 50,000 to 100,000 lines of code. I
don't want wrapped scripts. I want re-usable functions, objects, etc.
As developers learn to write native handlers they are starting down the
path that gets them ready for more serious action (namespace management,
using lexicals properly, etc . . . )
That being said perl is all about getting your job done before you get
fired. So an elegant registry solution should never be looked down upon
just because its a registry solution.
On Wed, 29 Mar 2000, Matt Arnold wrote:
Many messages on this list perpetuate the notion that usage of CGI.pm and
Apache::Registry is for beginners. Popular opinion is that you're not a
leet mod_perl h@x0r until you wean yourself from CGI.pm and Apache::Registry
and "graduate" to the Apache API. With this in mind, there have been many
messages over the years making blanket statements along the lines of "CGI.pm
is evil" and/or "Apache::Registry sux". I'm trying to identify the source
of this disatisfaction. While it may seem that my intent is to start the
ultimate, end-all CGI.pm/Apache::Registry flame war, please be assured that
I am interested in ferreting out the real issues. :-)
Anyway, in hope of generating some debate, I'll make some (potentially
inflammatory) assertions:
1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
The "Apache::Registry sux" crowd claims I should forgo Apache::Registry and
write handlers instead. Okay, here's my handler:
# in httpd.conf
Location /foo
SetHandler perl-script
PerlHandler Apache::Foo
/Location
package Apache::Foo;
use strict;
use CGI ();
sub handler {
my $q = CGI-new;
print $q-header;
print "Hello World\n";
200;
}
1;
Satisfied? No Apache::Registry in use here. Am I a l33t h@x0r now? No?
Why not? Oh, so when the zealots say, "Apache::Registry sux, write handlers
instead" they really mean I should be using the Apache API instead of
CGI.pm. I see.
I have another beef with the "CGI emulation sux, avoid Apache::Registry"
crowd. And that is:
2. Just because you don't use Apache::Registry doesn't mean you're not doing
CGI emulation (*gasp*)
What exactly is this "evil, bloated, slow CGI emulation" that everyone's
trying to avoid? Is it the overheard of setting up all the environment
variables? Well, gee whiz, regular handlers do this too unless you tell
them not to. Try the following exercise:
Location /env
#PerlSetupEnv Off # try first without; then try with PerlSetupEnv Off
SetHandler perl-script
PerlHandler Apache::Env
/Location
package Apache::Env;
use strict;
use Data::Dumper qw(Dumper);
sub handler {
my $r = shift;
$r-content_type('text/plain');
$r-send_http_header;
$r-print(Dumper(\%ENV));
200;
}
1;
So let's not be so quick to curse Apache::Registry for it's "slow" CGI
emulation. Your "fast" handlers are probably doing the same thing
unbeknownst to you.
Another assertion:
3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
It seems the "Apache::Registry sux" crowd dislikes Apache::Registry because
it implies that CGI.pm is in use. Perhaps their real gripe is one should
use the Apache API instead of CGI.pm's methods. So how would they feel
about this:
# in httpd.conf
Location /bar
PerlSetupEnv Off # we don't need no stinking ENV
SetHandler perl-script
PerlHandler Apache::Registry # or Apache::RegistryNG-handler
Options +ExecCGI
/Location
#!/usr/local/bin/perl -w
use strict;
my $r = Apache-request;
$r-content_type("text/html");
$r-send_http_header;
$r-print("Hi There!");
Does this count? Am I a l33t h@x0r because I used the Apache API? Or am I
still a lamer for using Apache::Registry?
I can hear the hordes out there crying, "Why use Apache::Registry if you're
not using CGI.pm?" Well, perhaps I have a couple hundred scripts and don't
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
I came across poorly in my original message. Some of my wording (e.g. l33t, h@x0r, sux, etc.) was a poor attempt at trying to make the message entertaining. :-( Shrug I feel badly that my poor wording and/or extreme tone is getting in the way of the intent. I sincerely want to learn the performance issues of CGI.pm and Apache::Registry. I'm sorry for the miscommunication. If you find the message too inflammatory, please delete. Sorry (really), Matt
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
[EMAIL PROTECTED] (Matt Arnold) wrote: 1. An Apache handler doesn't mean CGI.pm *ISN'T* in use 2. Just because you don't use Apache::Registry doesn't mean you're not doing CGI emulation (*gasp*) 3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use 4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods) I think somewhere you got confused about the relationship between Apache::Registry and CGI.pm, and now you're starting to get unconfused. But that doesn't mean that everyone else was confused the same way you were. CGI.pm and Apache::Registry are independent. You can use one without the other very easily. No need to associate them in this email. Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of you don't want to use CGI.pm for anything. While some of CGI.pm's functionality can be done more efficiently by other means (i.e. Apache::Request), CGI.pm's HTML methods have no such high-efficiency equivalents. Since laziness is one of the primary Perl virtues, isn't it smart to leverage the work already done in CGI.pm rather than rolling your own HTML methods? Can't using CGI.pm's HTML methods be considered a "good thing"? Of course, a lot of people like them. I don't use them, though. HTML is a perfectly valid language, and I don't see why I should use Perl to create HTML. It feels like using Java to write C. If you're using one of the embedded Perl solutions like HTML::Mason friends, one of the goals is to let HTML be HTML and let Perl be Perl. The recent thread "[ot] How to crypt the way htpasswd does..." serves as an example of how one can get chastised for failure to use existing code. (See http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why are so many of you quick to ignore this advice? Why is this particular wheel one so many of you are willing to reinvent? Well, one could make the argument that CGI.pm reinvented the wheel too - the HTML wheel. Would the anti-CGI.pm crowd be more likely to use these HTML functions if they were in their own (presumably leaner) module unbundled from the "bloated, monolithic" CGI.pm? No, I doubt it. At least, I wouldn't. There's nothing wrong with the HTML-generation side of CGI.pm, it just does things that I don't need to do, so I don't tend to use it. Perhaps this is what most of you performance mongers really mean. It's not helpful to call people names like that. People are just trying to get things done. By the way, you haven't mentioned the biggest reasons that people might want to avoid Apache::Registry. It will do a stat() on your script to see if it's changed, and set up several things (including %ENV, which you mentioned) just to emulate the CGI environment. There's no real reason to set these things up, it's just for CGI compatibility. So if you don't need CGI compatibility, doesn't it make sense that you shouldn't waste effort setting these things up? Apache::Registry makes a lot of sense for people who need to keep their scripts portable and CGI-compatible. Same with CGI.pm. No reason to couch things in your black/white good/bad terms, as there is a time to use all of these very popular tools and a time to choose other tools. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: performance mongers: since when is using CGI.pm or Apache::Registry dishonorable?
[EMAIL PROTECTED] (Matt Arnold) wrote: I came across poorly in my original message. Some of my wording (e.g. l33t, h@x0r, sux, etc.) was a poor attempt at trying to make the message entertaining. :-( Shrug I feel badly that my poor wording and/or extreme tone is getting in the way of the intent. I sincerely want to learn the performance issues of CGI.pm and Apache::Registry. I'm sorry for the miscommunication. If you find the message too inflammatory, please delete. Thanks for the clarification. In general, I find the performance differences between *any* of the various mod_perl solutions to be of only minor importance. There's not a whole lot of difference between really fast and super fast, because both are faster than I really need, and faster than my clients can accept the content anyway. Of far greater importance is whether you can organize your code well using a particular solution, whether you can scale your efforts well, and so on. This means that some people will enjoy the approach of Apache::Registry, others Apache handler modules, or things like HTML::Mason or HTML::Embperl. Mason is the tool I like the best, just because I can organize things well and it just "feels right" to me. But I wouldn't try to change anyone's mind if they liked a different tool more. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Error in Installation
Hello! I get the below errors when I try to install(perl Makefile.PL) modperl. Could someone help me out? Thanks, Ramesh Using config file: /opt/users/ramesh/software/mod_perl-1.22/src/Configuration Creating Makefile + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; gcc -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00503/i386-linux/CORE -I. -I../.. -DUSE_PERL_SSI -DMOD_PERL -o helpers/dummy helpers/dummy.c `perl /opt/users/ramesh/software/mod_perl-1.22/src/modules/perl/ldopts ` -lm /usr/local/lib/libc.so.6: undefined reference to `_dl_origin_path@@GLIBC_2.1.1' /usr/local/lib/libc.so.6: undefined reference to `_dl_lazy@@GLIBC_2.1.1' /usr/local/lib/libc.so.6: undefined reference to `_dl_dst_count@@GLIBC_2.1.1' /usr/local/lib/libc.so.6: undefined reference to `_dl_dst_substitute@@GLIBC_2.1.1' /usr/local/lib/libc.so.6: undefined reference to `_dl_platformlen@@GLIBC_2.1.1' collect2: ld returned 1 exit status make: *** [dummy] Error 1 = End of Error Report = Aborting! PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'ramesh' Group: 'users' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Checking if your kit is complete... Looks good Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl
Re: possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)
Support for strings represented as a vector of ordinals
Literals of the form Cv1.2.3.4 are now parsed as a string composed
of characters with the specified ordinals. This is an alternative, more
readable way to construct (possibly unicode) strings instead of
interpolating characters, as in C"\x{1}\x{2}\x{3}\x{4}". The leading
Cv may be omitted if there are more than two ordinals, so C1.2.3 is
parsed the same as Cv1.2.3.
Strings written in this form are also useful to represent version "numbers".
It is easy to compare such version "numbers" (which are really just plain
strings) using any of the usual string comparison operators Ceq, Cne,
Clt, Cgt, etc., or perform bitwise string operations on them using C|,
C, etc.
In conjunction with the new C$^V magic variable (which contains
the perl version as a string), such literals can be used as a readable way
to check if you're running a particular version of Perl:
# this will parse in older versions of Perl also
if ($^V and $^V gt v5.6.0) {
# new features supported
}
Crequire and Cuse also have some special magic to support such literals.
They will be interpreted as a version rather than as a module name:
require v5.6.0; # croak if $^V lt v5.6.0
use v5.6.0; # same, but croaks at compile-time
Alternatively, the Cv may be omitted if there is more than one dot:
require 5.6.0;
use 5.6.0;
Also, Csprintf and Cprintf support the Perl-specific format flag C%v
to print ordinals of characters in arbitrary strings:
printf "v%vd", $^V; # prints current version, such as "v5.5.650"
printf "%*vX", ":", $addr; # formats IPv6 address
printf "%*vb", " ", $bits; # displays bitstring
See Lperldata/"Scalar value constructors" for additional information.
=head2 Improved Perl version numbering system
Beginning with Perl version 5.6.0, the version number convention has been
changed to a "dotted integer" scheme that is more commonly found in open
source projects.
Maintenance versions of v5.6.0 will be released as v5.6.1, v5.6.2 etc.
The next development series following v5.6.0 will be numbered v5.7.x,
beginning with v5.7.0, and the next major production release following
v5.6.0 will be v5.8.0.
The English module now sets $PERL_VERSION to $^V (a string value) rather
than C$] (a numeric value). (This is a potential incompatibility.
Send us a report via perlbug if you are affected by this.)
The v1.2.3 syntax is also now legal in Perl.
See LSupport for strings represented as a vector of ordinals for more on
that.
To cope with the new versioning system's use of at least three significant
digits for each version component, the method used for incrementing the
subversion number has also changed slightly. We assume that versions older
than v5.6.0 have been incrementing the subversion component in multiples of
10. Versions after v5.6.0 will increment them by 1. Thus, using the new
notation, 5.005_03 is the "same" as v5.5.30, and the first maintenance
version following v5.6.0 will be v5.6.1 (which should be read as being
equivalent to a floating point value of 5.006_001 in the older format,
stored in C$]).
Re: loading of mod_perl
Randy: Thanks for replying my message. First of all, my Perl os working and I can run some perl program in cgi-bin directory from browser. The c:\perl\bin is of course in the path. My Perl version is : v5.6.0 built for MSWin32-x86-multi-thread. Apache version is the lastest 1_3_12 (Win32) and Mod_perl is 'mod_perl-1.16-bin-bindist1-i386-win32-vc5', which is compiled by Viusal C++ 5.0. This is the only Win32 version of mod_perl I can find. I download the mod_perl from CPAN in the author directory of /Jeffrey_Baker/. I did not do any compilation at all. I need more suggestion from you or it is not a good idea to run the server on Win98. Thanks, Xingjian - Original Message - From: "Randy Kobes" [EMAIL PROTECTED] To: "shang" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 29, 2000 8:49 AM Subject: Re: loading of mod_perl On Wed, 29 Mar 2000, shang wrote: Hi, I have some problem loading ApacheModulePerl.dll into Apache server I installed in Windows 98. All the other *.dll in c:\apache\modules can be loaded but not this one. The following is the error message when I typed 'apache -s' : (The line 188 actually contains the 'LoadModule perl_module modules/ApacheModulePerl.dll' ) Syntax error on line 188 of c:/apache/conf/httpd.conf: Cannot load c:/apache/modules/ApacheModulePerl.dll into server: Hi, Does Perl work OK otherwise? For example, does 'perl -v' print out the version number? Does your PATH contain the perl binary? Was the apache, perl, and mod_perl distributions (including ApacheModulePerl.dll) compiled with the same compiler? In particular, was ApacheModulePerl.dll compiled with the same version of Apache that you're now using? best regards, Randy Kobes
