Hello, every body
I can run the following subroutine in DBI, but Apache::DBI...
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,3dsadasz);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die
It looks like your PostgreSQL installation is trying to do IDENT
authentication, instead of MD5. So, it's checking the user your script is
running as, and trusting that since you managed to log on with your
username/password already, it'll trust you to log into the database.
While this isn't
I can run the following code with DBI
but in Apache::DBI.
#!/usr/bin/perl -w
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,$password);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row =
Hi All,
I'm having a weird problem using SOAP::Lite in one of my mod_perl
modules.
A snippet of my code is:
sub _dispatch {
my $self = shift;
my $proxy = http://our.stats.server.com.au/soap/script.cgi;;
my
simran wrote:
The above code works perfectly on:
* On dev server in a standalone script
* On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c
DAV/1.0.3 mod_perl/1.27
* Our live server as a standalong script
The code does not work on our live server under:
* Live
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
undef local $/;
my $rv = FROMADMIN; # get response
close FROMADMIN;
return $rv;
}
else {
Michael wrote:
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
[...]
This works fine for command line exection and from cgi but fails in
modperl (apache 1x).
The problem
Thanks Perrin.
I'll try a recompile with Apache 1.27 as suggested... not brave enough
to eventually put a patched 1.28 on our live server yet :-)
simran.
On Fri, 2003-08-29 at 11:25, Perrin Harkins wrote:
simran wrote:
The above code works perfectly on:
* On dev server in a
Hi Perrin,
I just recompiled everything with 1.27 (and relevant mod_ssl module) and
everything is working wonderfully again.
thankyou again every so much for your help, i had been struggling with
it for days...
simran.
Hi guys,
On Thu, 28 Aug 2003, Perrin Harkins wrote:
simran wrote:
The above code works perfectly on:
* On dev server in a standalone script
* On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c
DAV/1.0.3 mod_perl/1.27
* Our live server as a standalong
Ged Haywood wrote:
Hi guys,
On Thu, 28 Aug 2003, Perrin Harkins wrote:
simran wrote:
The above code works perfectly on:
* On dev server in a standalone script
* On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c
DAV/1.0.3 mod_perl/1.27
* Our live server as a
Hi Stas,
On Fri, 29 Aug 2003, Stas Bekman wrote:
Ged Haywood wrote:
Have you mentioned this to Philippe Chiasson?
Beg your pardon, Ged? What this has to do with Philippe?
Wasn't he organising the release of mod_perl 1.28?
If people are moving to a 1.3.28/1.28 combination, I would expect
Have you mentioned this to Philippe Chiasson?
Beg your pardon, Ged? What this has to do with Philippe?
Wasn't he organising the release of mod_perl 1.28?
He was a release manager, not a person to blame, even if there was a problem
with 1.28, which is certainly not the case.
If people are
I was delighted to discover an nntp gateway news.gmane.org which carries the
following three archives:
docs-dev: nntp://news.gmane.org/gmane.comp.apache.mod-perl.devel
modperl:nntp://news.gmane.org/gmane.comp.apache.mod-perl
apreq-dev: nntp://news.gmane.org/gmane.comp.apache.apreq
They
On an unrelated note SOAP::Lite developement seems to have gone quite to me
anyway.
Greg
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Apologies for the off-topic post...
I'm looking for stories, annecdotes, comparisons, etc. from people who
are using extreme programming using Perl. Even if you are using only
some of the practices, such as, testing, coding, and refactoring, your
input will be useful. The good, the bad, the
Hello all,
I have perl programs running under Apache::Registry.
Now I need to switch to mod_perl2 and can not find request object.
I used to get as
$r = Apache-request;
But this does not work under mod_perl2.
Please advise how do something similar and avoid big changes in scripts.
Thank you
Hi All,
It looked like the Debian install problems were back.
[EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL
* WARNING *
Igor Ivoilov wrote:
Hello all,
I have perl programs running under Apache::Registry.
Now I need to switch to mod_perl2 and can not find request object.
I used to get as
$r = Apache-request;
But this does not work under mod_perl2.
Hi!
My guess is that you've been hit by this Apache problem:
http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile
As the URL above suggests, try to add 'EnableSendfile On' somewhere in
t/conf/httpd.conf and rerun:
t/TEST -v filter/in_bbs_msg.t hooks/trans.t
don't run 'make
The doc you reference says that Apache-request should be avoided because
it is expensive. But does it in fact work?
-Paul
On Fri, 29 Aug 2003 10:17:57 -0700, Stas Bekman [EMAIL PROTECTED] wrote:
Igor Ivoilov wrote:
Hello all,
I have perl programs running under Apache::Registry.
Now I need to
On Thu, Aug 28, 2003 at 06:43:42PM -0700, Stas Bekman wrote:
Michael wrote:
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
[...]
This works fine for command
Paul G. Weiss wrote:
The doc you reference says that Apache-request should be avoided
because it is expensive. But does it in fact work?
Yes. Have you actually read it? That section also explains when it's available.
Igor said: this does not work under mod_perl2, without showing any error
Hi All,
On Wed, 2003-08-27 at 02:33, Geoffrey Young wrote:
hi craig.
before we continue, please try the latest cvs (without the patch I sent)
and see if your stuff segfaults there. if not, at least we know we've
isolated the segfault and just have bad logic to fix :)
Well:
It seg
Alan Rafagudinov wrote:
Hi!
My guess is that you've been hit by this Apache problem:
http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile
[...]
Thank you, but your advice helped with hooks/trans.t only,
ok, I have added this to the troubleshooting section.
filter/in_bbs_msg.t is still
Craig Shelley wrote:
Hi All,
It looked like the Debian install problems were back.
[EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL
* WARNING *
I am experimenting with using mod_perl 1.2x as a DSO and have noticed that
it does not share much memory between process and also seems to utilize
much more memory.
I thought that it is possible to use mod_perl 1.2x as a DSO when perl is
compile with -Uusemymalloc and -Ubincompat5005 which it
I'm about to release a new GTop (you need it for Apache::VMonitor), please
give it a try http://apache.org/~stas/GTop-0.11.tar.gz and report any problems
to me (off list). Thanks.
Changes since 0.10:
Add support to libgtop 2.0 and automate the picking of the right libraries
and include paths.
Hi there,
On Fri, 29 Aug 2003, Stathy G. Touloumis wrote:
should building a DSO in mod_perl 1.x versions just be avoided?
I think so, and so I think does Randal. This was discussed briefly
here not long ago in a couple of threads, check the archives.
73,
Ged.
--
Reporting bugs:
should building a DSO in mod_perl 1.x versions just be avoided?
I think so, and so I think does Randal. This was discussed briefly
here not long ago in a couple of threads, check the archives.
Thanks, I will check the archives.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info:
Sorry that I neglected to list all info :
Apache version 1.3.27
mod_perl version 1.26
OS version RedHat Linux 2.4.20-18.7
perl -V :
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.18-3smp, archname=i386-linux
uname='linux
Sorry for not pointing out all details
config file
FilesMatch \.pl$
SetHandler perl-script
PerlHandler ModPerl::Registry::handler
PerlOptions +ParseHeaders
AddType text/html .pl
Options +ExecCGI
/FilesMatch
my $r = Apache-request;
gives Can't locate object
I've installed Apache::DProf, but it seems hardly any of the calls are
profiled. dprofpp shouws MOF::Dispatcher::handler as taking up 100%
of the time, but there is no information recorded in for calls within
that function. MOF::Dispatcher::handler is calling thousands of other
functions
On Fri, 2003-08-29 at 17:11, Brian Hirt wrote:
I've installed Apache::DProf, but it seems hardly any of the calls are
profiled.
You probably compiled that code before you initialized the debugger.
Add a call to Apache::DB-init before you load your modules, as
described in the Apache::DB docs.
Brian Hirt wrote:
I've installed Apache::DProf, but it seems hardly any of the calls are
profiled. dprofpp shouws MOF::Dispatcher::handler as taking up 100% of
the time, but there is no information recorded in for calls within that
function. MOF::Dispatcher::handler is calling thousands of
Igor Ivoilov wrote:
Sorry for not pointing out all details
config file
FilesMatch \.pl$
SetHandler perl-script
PerlHandler ModPerl::Registry::handler
PerlOptions +ParseHeaders
AddType text/html .pl
Options +ExecCGI
/FilesMatch
my $r = Apache-request;
gives
36 matches
Mail list logo
