I tried that as well, before, did not work ..
just verified it again:
[Fri Oct 24 02:47:20 2003] [error] Undefined subroutine
&Apache::RegistryBB->handler::handler called.
PH> On Thu, 2003-10-23 at 22:22, justin wrote:
>> # runtime, this location generates the error, browser sees 500 internal s
On Thu, 2003-10-23 at 22:22, justin wrote:
> # runtime, this location generates the error, browser sees 500 internal server error
>
> SetHandler perl-script
> PerlHandler Apache::RegistryBB
>
As Geoff pointed out, this is a method handler, so try this instead:
PerlHandler Apache::RegistryBB-
Randy,
> > httpd starts perfectly without mod_perl. When "LoadModule mod_Perl
> > modules/mod_perl.so" is included in http.conf, httpd fails to start and
> > reports the following message:
>
> Try instead
>LoadModule perl_module modules/mod_perl.so
Thank you very much! You have fixed my proble
On Thu, 23 Oct 2003, CN wrote:
> Hi!
>
> Please help!
> Regards,
> CN
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
>
> httpd starts perfectly without mod_perl. When "LoadModule mod_Perl
> modules/mod_perl.so" is included in http.conf, httpd fails
Hi!
Please help!
Regards,
CN
-8<-- Start Bug Report 8<--
1. Problem Description:
httpd starts perfectly without mod_perl. When "LoadModule mod_Perl
modules/mod_perl.so" is included in http.conf, httpd fails to start and
reports the following message:
Synta
Yep, that is there fine already..
PerlModule Apache::Filter
PerlModule Apache::RegistryNG
PerlModule Apache::RegistryBB
PerlModule Apache::Compress
PerlModule Apache::RegistryFilter
SetHandler perl-script
PerlHandler Apache::RegistryNG
# runtime, this location generates the error, browser
justin wrote:
Although I can get RegistryNG working just fine, I can't seem to get
RegistryBB working. It insists it cannot find the handler, even though I
should be able to just change NG to BB in the config file, right?
RegistryBB seems not to have changed since modperl 1.13 or prior, and
was u
Although I can get RegistryNG working just fine, I can't seem to get
RegistryBB working. It insists it cannot find the handler, even though I
should be able to just change NG to BB in the config file, right?
RegistryBB seems not to have changed since modperl 1.13 or prior, and
was usable there.
The URL
http://perl.apache.org/~geoff/Apache-Test-1.05.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.05.tar.gz
size: 92764 bytes
md5: 53654c4e47240d2494db010a0a15751d
Changes since 1.04:
core scanning changes [Stas]
- speedup by not chdir'ing into subdirs
At 08:41 AM 10/23/2003 +0100, Ged Haywood wrote:
>I know nothing about the Apachetoolbox, I've never used it, but I'd be
>surprised if there's no documentation with it. Perhaps you'll need to
>reinstall the Apachetoolbox now you have a new Perl. I take it the new
>Perl is now the default in your
On Thu, 2003-10-23 at 14:56, Brendan W. McAdams wrote:
> Tried timestamping the second layer, and saving directly, no luck.
The timestamp has to be in the first layer. It doesn't have to be a
timestamp, actually. Any write at all in the first layer is fine, e.g.
$session{'changed'} = 1.
I forgo
Perrin Harkins wrote:
On Thu, 2003-10-23 at 14:42, Geoffrey Young wrote:
You don't have to, but if you don't and the Oracle connection gets lost
and Apache::DBI reconnects, your stale statement handles will all fail.
The best thing to do is use prepare_cached. This will use an already
prepared
Tried timestamping the second layer, and saving directly, no luck.
Shrugged and dropped the midlevel tax_swap hash and it's working now.
Thanks.
On Thu, 2003-10-23 at 14:16, Perrin Harkins wrote:
> Hi Brendan,
>
> > I'm trying to store an object (simple datatype, just a blessed hash
> > inside
On Thu, 2003-10-23 at 14:42, Geoffrey Young wrote:
> > You don't have to, but if you don't and the Oracle connection gets lost
> > and Apache::DBI reconnects, your stale statement handles will all fail.
> > The best thing to do is use prepare_cached. This will use an already
> > prepared statemen
Thanks Perrin, your always full of good answers :)
> On Thu, 2003-10-23 at 13:00, Levon Barker wrote:
>> Should I be making new statement handlers for every new request?
>
> You don't have to, but if you don't and the Oracle connection gets lost
> and Apache::DBI reconnects, your stale statement
You don't have to, but if you don't and the Oracle connection gets lost
and Apache::DBI reconnects, your stale statement handles will all fail.
The best thing to do is use prepare_cached. This will use an already
prepared statement handle if possible.
I haven't done any of this in a very long ti
On Thu, 2003-10-23 at 13:00, Levon Barker wrote:
> Should I be making new statement handlers for every new request?
You don't have to, but if you don't and the Oracle connection gets lost
and Apache::DBI reconnects, your stale statement handles will all fail.
The best thing to do is use prepare_c
Hi Brendan,
> I'm trying to store an object (simple datatype, just a blessed hash
> inside) within Apache::Session. I'm doing this:
> $session->{tax_swap}->{preview_sell_candidates} = [EMAIL PROTECTED];
> where @items is an array of SellCandidate objects... I've stored array
> references in Apac
I also should note that the following subroutine works:
# Persists sell candidates to session storage
# Should take an array of
Apache::MuniCenter::MarkupMatrix::TaxSwap::Candidate Objects
# Should this be redone as an object (Yes, but question is when..)
sub savePreviewSellList {
my $sess
I'm trying to store an object (simple datatype, just a blessed hash
inside) within Apache::Session. I'm doing this:
$session->{tax_swap}->{preview_sell_candidates} = [EMAIL PROTECTED];
where @items is an array of SellCandidate objects... I've stored array
references in Apache::Session before; is
I have a little more data.
I don't think its the database handler that is giving me trouble. I think
its the statement handler. As some other queries work in the same module
before I get to the statement handler that is breaking.
Should I be making new statement handlers for every new request? Do
Ok, everyone, sorry to have bothered you with this. Turns out it didn't
have anything to do with modperl or apache, but that I was just missing
some stuff from CGI::Simple. By default, CGI.pm (which I was used to)
enables file uploads of unlimited size; by contrast CGI::Simple's
default is to disab
Hello,
(my last message got cut off)
Can someone verify that this is the right way to use DBI and mod_perl (with
Apache::DBI of course). I get problems where if the user cancels a request
before my module has finished accessing my Oracle db, the module does not
work for any ongoing requests until
Hello,
Can someone verify that this is the right way to use DBI and mod_perl (with
Apache::DBI of course). I get problems where if the user cancels a request
before my module has finished accessing my Oracle db, the module does not
work for any ongoing requests until I restart the Apache server. T
Hi all,
just for statistics informations, I've successfully built (from sources, w/gcc
3.2.3) Perl/5.8.1, Apache/2.0.47 and mod_perl/1.99_10 on Slackware 9.1 (2.4.22,
Intel)
by
- Enrico
Ah wise man speaketh!
Greg
> -Original Message-
> From: Barry Hoggard [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 16:54
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Apachetoolbox] How to choose your Perl?
>
>
> I use a perl set up like this so that I'm immune from any RPM
> changes on
I use a perl set up like this so that I'm immune from any RPM changes on
my rpm-based servers.
/opt/perl
is a symlink to the perl I'm using:
/opt/perl-5.8.1
I use /opt/perl/ to build mod_perl, and #!/opt/perl/bin in my scripts.
Make sure you have the right perl in your path when you add CPAN
Randy wrote:
Shannon,
Thank you for getting back to me!
I am running a newer version of apache that only has
the httpd.conf configuration file. The text that I
placed in the file is as follows:
#
# Stuff added by Randy
> -Original Message-
> From: Brendan W. McAdams [mailto:[EMAIL PROTECTED]
> Not familiar with apachetoolbox but I'm familiar with the problem in
> general; we had problems with SA's monkeying around with modules and
> perl installs on our prod boxes (thus breaking the production mod_perl
Not familiar with apachetoolbox but I'm familiar with the problem in
general; we had problems with SA's monkeying around with modules and
perl installs on our prod boxes (thus breaking the production mod_perl
install), and began packaging our own perl binary in our home directory.
As long as your
Hi there,
On Thu, 23 Oct 2003, John Day wrote:
> I am using RH8.0. I used Apachetoolbox to build an
> Apache/mod_ssl/mod_perl system with the supplied Perl 5.8.0, Apache
> 1.3.28 and mod_perl 1.28. For my task I need Date::Calc - which had
> serious problems compiling on the Perl 5.8.0 because o
31 matches
Mail list logo
