On Sun, 2003-08-17 at 22:15, Cory 'G' Watson wrote:
> No, I only had a 'use App;' in my startup.
Your startup comes before the virtual host sections then?
> When I added a caller() to the top of my module, I saw the initial
> startup.pl use(), and then a later eval() that I couldn't track. When
> On Sat, 2003-08-16 at 01:46, Cory 'G' Watson wrote:
> Well, first of all, you're just asking for trouble if you turn on
> PerlFreshRestart. Don't do it.
I forget why I added it. My (poor) memory seems to recall something from
the Eagle book causing me to add it. I'd never seen the 'evil' doc
On Sat, 2003-08-16 at 01:46, Cory 'G' Watson wrote:
> %somehash = ();
>
> This declaration is outside of any subroutines.
Okay, so your subs that refer to it are now closures. That could be
part of the issue. If you make %somehash a real global, it might help.
> I re-attacked this problem by a
Hi there,
On Sat, 16 Aug 2003, Cory 'G' Watson wrote:
> started flipping switches and localized it to PerlFreshRestart being on.
Have you read
http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Evil_things_might_happen_when_using_PerlFreshRestart
> When I turn it off, the eval() happen
On Friday, August 15, 2003, at 06:23 PM, Ged Haywood wrote:
Ignore syntax errors and lack of declarations, as I just threw that
together from memory
The guesswork would be a lot easier if it didn't involve so much
guesswork. :)
I think the root question of my email was lost in my poor explanation
Hello again,
On Fri, 15 Aug 2003, Cory 'G' Watson wrote:
> PerlVar app blah
>
> App->loadApp("blah", "/usr/local/blah/lib");
>
> [snip]
> Ignore syntax errors and lack of declarations, as I just threw that
> together from memory
The guesswork would be a lot easier if it didn't involve so mu
On Friday, August 15, 2003, at 12:43 PM, Ged Haywood wrote:
I'm not entirely convinced of the explanation, but have you tried
testing the value of $Apache::Server::ReStarting in the code that
fills the hash? It's in the Guide.
I'm not convinced of it either. :)
This code _would_ run twice, so I
Hi there,
On Fri, 15 Aug 2003, Cory 'G' Watson wrote:
> It looks as though this works during the first 'load' that Apache does,
> which I'm assuming is the phase that checks for errors. The second
> phase seems to cause my global hash to get undef'ed, even though the
> loadPages() method work
I've recently written some code that behaves in a way I don't
understand. It's basically a Handler that works for more than one
VirtualHost. For each VirtualHost that uses the Handler, a call is
made to App->loadPages(). It crawls an accompanying lib directory and
loads the pages into a hash
Here's my perl.conf (sourced by httpd.conf)
start
LoadModule perl_module modules/mod_perl.so
PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff
on second thought, try
PerlSwitches -I/home/bruce/public_html/ffball/myff
or
PerlSwitches -Mlib=/home/bruce/public_html/ffbal
Hi Folks
Fascinating to see this on a non-Windows box.
Reloading modules after they have been editied, eg httpd like so:
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadModules "CGI CGI::Application ... Sweep::*"
works about 99% o
Bruce Tennant wrote:
I'm trying to do some development work with mod_perl and find
restarting the server a pain. So I setup Apache::Reload, but it
doesn't seem to want to see my local devel directory all the time.
Here's my settings
Apache/2.0.40
mod_perl-1.99_7
please upgrade to
Forwarding message as I didn't realize I was missing the list.
Geoffrey Young <[EMAIL PROTECTED]> wrote:
Date: Tue, 12 Aug 2003 14:18:37 -0400From: Geoffrey Young <[EMAIL PROTECTED]>To: Bruce Tennant <[EMAIL PROTECTED]>Subject: Re: Apache::Reload and INC path partialy work
I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time.Here's my settingsApache/2.0.40mod_perl-1.99_7Linux 2.4.20-8 (RedHat9 I think)Here
Ugh! Not use to lists that reply to author.
Okay to resay what I sent to Geoffrey.
using the -I switch in the config file works, unlike the PerlSetEnv PERL5LIBGeoffrey Young <[EMAIL PROTECTED]> wrote:
>> Here's my perl.conf (sourced by httpd.conf)>> start LoadModule pe
On Fri, 2003-08-01 at 11:10, Roger Davenport wrote:
> I've been working with Apache::Reload and Registry and have been
> unable to get any cache flushing to work. (I've added debug messages
> in Registry to show cache use or reloading).
Can you tell us what you are trying to
I've been working
with Apache::Reload and Registry and have been unable to get any cache flushing
to work. (I've added debug messages in Registry to show cache use or
reloading).
I've tried this
combination: (httpd.conf)
PerlModule
Apache::RegistryPerlModu
--- Original Message ---
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: Ron Savage <[EMAIL PROTECTED]>
Cc:
Sent: Sat, 01 Mar 2003 12:47:39 +1100
Subject: Re: [MP2] Apache::Reload date bug
>Ron Savage wrote:
>>On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote:
>
On Wed, 26 Feb 2003 22:30:51 -0600 (CST), Randy Kobes wrote:
>On Thu, 27 Feb 2003, Ron Savage wrote:
>
>>On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote:
HI Randy
>The mod_perl 2 ppm package (for ActivePerl 8xx) at
>http://theoryx5.uwinnipeg.ca/ppms/ is updated
>periodically with a cvs buil
On Thu, 27 Feb 2003, Ron Savage wrote:
> On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote:
>
> Hi Stas
>
> >Have you tried the current mod_perl cvs?
>
> No. Being usually a Windows (shudder) user, I wait for Randy to issue
> a build.
The mod_perl 2 ppm package (for ActivePerl 8xx) at
htt
On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote:
Hi Stas
>Have you tried the current mod_perl cvs?
No. Being usually a Windows (shudder) user, I wait for Randy to issue
a build.
Today I spent 4 hours failing to install Red Hat 6, Red Hat 8 and
Mandrake 9 on a brand new Dell with a 82854G/
Ron Savage wrote:
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote:
And what your error_log says?
Nothing is output to the error_log.
Have you tried the current mod_perl cvs?
__
Stas BekmanJAm_pH --> Just Anot
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote:
>And what your error_log says?
Nothing is output to the error_log.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 25/02/2003
http://savage.net.au/index.html
Ron Savage wrote:
On Wed, 19 Feb 2003 10:04:02 +1100, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
Hi Folks
In endeavouring to reproduce this problem, I've encountered another:
main.cgi:
-><8-
#!/usr/bin/perl
use strict;
use warnings;
use C
e part of httpd.conf controlling /perl/. Note Dummy is not included
here, but the original module, which revealed the original bug, is:
><8
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadModules "CGI::Explorer DBIx::AdminEn
ot;
foo
C:\Backup>perl -le 'warn("foo\n")'
well, you've got the idea, right.
Perhaps someone on win32 can try to debug the behavior that you
saw. I can't reproduce it on my linux box.
With my ActivePerl 8xx compatible perl-5.8, sticking in a
warn("foo
eproduce it on my linux box.
With my ActivePerl 8xx compatible perl-5.8, sticking in a
warn("foo\n");
inside a simple handler that uses Apache::Reload
just output "foo" in the error log, with no timestamp
nor client reported, as expected. I'm wondering though
if this is com
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
perl -le 'warn("foo\n")'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backup>perl -le "warn(qq|foo\n|)"
foo
C:\Backup>perl -le 'warn("foo\n")'
well, you've got the idea, right.
Perhaps someone on w
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
>perl -le 'warn("foo\n")'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backup>perl -le "warn(qq|foo\n|)"
foo
C:\Backup>perl -le 'warn("foo\n")'
C:\Backup>
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 19/02/2003
http://savage
Ron Savage wrote:
Folks
I don't know if this an Apache problem, or a mod_perl problem.
Apache::Reload outputs a UTC date rather than a local date, when it
encounters an error. Here's an excerpt from my log.
Notice how the dates go Sun, Mon, ..., Sun.
[Sun Feb 16 18:31:25 2003] [erro
For those who started working with mp2 and found themselves unable to use
Apache::Reload for connection filters and protocol handlers, I'm happy to tell
you that the cvs version now supports Apache::Reload in the
PerlPreConnectionHandler phase, which happens as early as possible. The
up
Folks
I don't know if this an Apache problem, or a mod_perl problem.
Apache::Reload outputs a UTC date rather than a local date, when it
encounters an error. Here's an excerpt from my log.
Notice how the dates go Sun, Mon, ..., Sun.
[Sun Feb 16 18:31:25 2003] [error] [client
Geoffrey Young wrote:
Richard Curtis wrote:
Hi again group.
A quick question (but this might not be the right place).
If this is the wrong place to ask, please point me in the direction of
the
right place.
you're in the right place, don't worry :)
I have a web app written using mod_pe
pache::ASP.
When I change the code in a perl module, I have to restart apache to make
the changes appear to all children.
Is there a way of avoiding this - maybe with an apache directive - so that
all modules are re-read by all children without a restart ?
Apache::Reload ships standard with mod_perl
Hi again group.
A quick question (but this might not be the right place).
If this is the wrong place to ask, please point me in the direction of the
right place.
I have a web app written using mod_perl2 and apache::ASP.
When I change the code in a perl module, I have to restart apache to make
t
h could be useful in both mod_perl
1.* and 2.0,
can it be applied to both distributions? I don't quite understand why
installing
Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll
try to think some more about it.
Because Apache::Reload is distributed on CPAN
Igor Vylusko wrote:
in doc
http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html
declared that when using Apache::Reload I may define additional lib
in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra
But when I enable PerlInitHandler Apache::Reload in config all libs defined
>> in doc
>> http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html
>> declared that when using Apache::Reload I may define additional lib
>> in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra
>> But when I enable PerlInitHandler Apache::Reload
Igor Vylusko wrote:
Hi All,
in doc
http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html
declared that when using Apache::Reload I may define additional lib
in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra
But when I enable PerlInitHandler Apache::Reload in config all libs
Hi All,
in doc
http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html
declared that when using Apache::Reload I may define additional lib
in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra
But when I enable PerlInitHandler Apache::Reload in config all libs defined in
PERL5LIB
> "KGM" == Keith G Murphy <[EMAIL PROTECTED]> writes:
KGM> When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
KGM> driver in my startup perl script thus:
Hmmm. Interesting theory. I shall have to investigate it. I also
see a multi-megabyte memory leak in my app when DB
Juha-Mikko Ahonen wrote:
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With DBI->install_driver('Pg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> OK, it gets weirder. The following script produces the leak. If I
> comment out the install_driver line, I get a big old segfault! Same
> if I comment out the Apache::DBI line in addition. This works with
> plain apache, or apache-ssl.
>
> #!/usr
[debian-isp readers, to recap, I'm trying to confirm a
memory-leak/segfault problem with Debian stable plus apache(-ssl) plus
libapache-mod-perl. The memory leak happens upon
/etc/init.d/apache(-ssl) reload. You can see my startup script and my
other comments below.]
Juha-Mikko A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
> It's not like it was an obvious problem: I only got the DSO to leak
> when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.
Daniel Jacobowitz wrote:
> On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote:
>>
>>My own bug report is now 47 days old, without apparent followup.
Hmmm, I probably should not have posted that. Sounds like a major whine.
>
>
> That's because I'm having an attack of real life. I
On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote:
> Ged Haywood wrote:
> >Hi there,
> >
> >On Wed, 16 Oct 2002, Keith G. Murphy wrote:
> >
> >
> >>do you mean that the problems with the loadable module overall are
> >>so well-known that no one in his right mind should ever use it?
>
Ged Haywood wrote:
> Hi there,
>
> On Wed, 16 Oct 2002, Keith G. Murphy wrote:
>
>
>>>Significant improvements have been made in
>>>the reliability of mod_perl as DSO and nowadays there is much less
>>>discussion about it on this list.
>>
>>Are you sure it's not because 'most everyone has sil
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
> > Significant improvements have been made in
> > the reliability of mod_perl as DSO and nowadays there is much less
> > discussion about it on this list.
>
> Are you sure it's not because 'most everyone has silently given up on it?
Yes,
eith G. Murphy [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 2:02 PM
> To: mod_perl Mailing List
> Subject: Re: Memory leak on reload when the 'Pg' driver is preloaded
>
>
> Ged Haywood wrote:
> > Hi there,
> >
> > On Wed, 16 Oct 2002, K
Juha-Mikko Ahonen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote:
>
>>By "should", do you mean that the problems with the loadable module
>>overall are so well-known that no one in his right mind should ever
>>use it?
>
>
Ged Haywood wrote:
> Hi there,
>
> On Wed, 16 Oct 2002, Keith G. Murphy wrote:
>
>
>>do you mean that the problems with the loadable module overall are
>>so well-known that no one in his right mind should ever use it?
>
>
> It's not as bad as that. Significant improvements have been made in
Hi there,
On Wed, 16 Oct 2002, Keith G. Murphy wrote:
> do you mean that the problems with the loadable module overall are
> so well-known that no one in his right mind should ever use it?
It's not as bad as that. Significant improvements have been made in
the reliability of mod_perl as DSO an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote:
> By "should", do you mean that the problems with the loadable module
> overall are so well-known that no one in his right mind should ever
> use it?
Yes. The problems with DSO mod_perl are w
Stathy G. Touloumis wrote:
>
>
>> Using Debian's static-mod_perled apache-perl eliminates the problem.
>
>
> Do you mean you are using the 'so' version that comes with Debian?
Yes, in the case that failed. The package is called 'libapache-mod-perl'.
>
> You
> should be using the static bui
>Using Debian's static-mod_perled apache-perl eliminates the problem.
Do you mean you are using the 'so' version that comes with Debian? You
should be using the static build of apache/mod_perl
Since memory leaks seem to be the topic du jour, I wondered if anyone
else had seen this one:
When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
driver in my startup perl script thus:
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI->install_driver
I started using a dynamic @INC (set up in a TransHandler), and discovered
that Apache::Reload (v0.07) was not doing its job correctly in that case.
Note, changing @INC in a transhandler won't have the desired Apache::Reload
effects unless the PerlInitHandler for Apache::Reload is placed
Ken Miller wrote:
> I've been successfully using Apache::Reload for a few weeks now. However, I
> installed it on my home development system, and I'm getting this error when
> accessing a module that contains 'use Apache::Reload':
>
> [Mon Aug 26 09:59:12 20
* Ken Miller <[EMAIL PROTECTED]> [2002-08-26 12:03]:
> What's main.pm, and why can't Apache::Reload find it? I've searched
> the archives, but have had little success in finding anything
> interesting.
Run
find $dir -name 'main.pm' -print
For
I've been successfully using Apache::Reload for a few weeks now. However, I
installed it on my home development system, and I'm getting this error when
accessing a module that contains 'use Apache::Reload':
[Mon Aug 26 09:59:12 2002] [error] Can't locate main.pm in @I
h could be useful in both mod_perl
> 1.* and 2.0,
> can it be applied to both distributions? I don't quite understand why
> installing
> Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll
> try to think some more about it.
Because Apache::Reload is
27;t quite understand why
installing
Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll
try to think some more about it.
Stas Bekman wrote:
> Harry Danilevsky wrote:
>
>> I certainly agree with attaching a common prefix to a library, but
>> what if I a
nd I'll sync the version in
mod_perl 2.0 (CC me). Though we need to figure out how to resolve the
versioning conflict. so when you ask for Apache::Reload from CPAN.pm, it
won't install mod_perl 2.0. Ideas?
> Stas Bekman wrote:
>
>> Harry Danilevsky wrote:
>>
>>
eed to add Reports to ReloadModules,
>> and restart the server.
>
>
> That's the thing. It's a good idea to alway use some prefix package
> name in all your modules, to avoid future clashes with other modules.
> And it automatically solves your problem with Apache::Reload.
>
e/lib/Reports.pm I'll need to add Reports to ReloadModules, and
> restart the server.
That's the thing. It's a good idea to alway use some prefix package name
in all your modules, to avoid future clashes with other modules. And it
automatically solves your problem with Apache
It appears from ReloadDebug's output that those cached files are being checked by
Apache::Reload,
and if they have been modified - they'll be reloaded. The problem is, if the code has
a syntax
error, that error will occur when Apache::Reload re-require()s that file, and the
error message
[...]
> Anyway, I decided to add another directive to Apache::Reload
>
> PerlSetVar ReloadDirectories "/site/lib /usr/local/apache/conf"
Apache::Reload allows you to define which modules to reload using the
patterns like so:
PerlSetVar ReloadAll Off
PerlSetVar ReloadMo
> The question I had regards where to put the 'Apache::Reload' directive.
> The documentation suggests something like:
>
>
>
> PerlInitHandler Apache::Reload
> PerlSetVar ReloadAll Off
>
> PerlSetVar ReloadTouchFile /tmp/reload_modules
>
&g
I've got a "reality check" question for
people to see that I'm not missing something obvious with our Apache::Reload
mod_perl setup.
We've recently install Apache::Reload at
our site in production and it's working great. In what is probably not the
best '
After much fluffing around I managed to get Apache::Reload to work for .pm
files with:
PerlRequire /the/path/to/the/perl/startup.pl
PerlInitHandler Apache::Reload
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
BUT
Is it possible to get simple
Hi folks,
I was wondering if there is a possibility to reload perl
module (and I want reloaded module in all Apache children processes) by
running reload-program once.
For example Apache::Reload must be set as PerlInitHandler, so
it's handler method is run every time request com
On Thu, 11 Apr 2002, Perrin Harkins wrote:
> Does it look you'll be able to get the solar variables idea to work for
> those data types?
i had a simple prototype way back that sorta worked for simple scalars,
probably won't take it any further now that there is threads::shared in
5.7.x. hav
[EMAIL PROTECTED] wrote:
> On Fri, 12 Apr 2002, Stas Bekman wrote:
>
>
>>But if talk about futuristic Solar variables (perl globals shared
>>between threads). what if a solar variable is a reference to CODE? Can
>>this be shared? If so, will reloading this variable in one interpreter
>>affec
eters in it, there can be a
> thread that monitors changed modules and update the idle interpreters by
> making them reload the code and put them in the head of the list. This
> should save the overhead of reloading during a request. Does this make
> sense?
there already is a plan
[EMAIL PROTECTED] wrote:
> if you use Apache::Reload with a threaded MPM and multiple interpreters,
> the modules will be reloaded by each interpreter as they are used, not
> every interpreter all at once. similar to 1.x where each child has
> its own interpreter, the modules are
if you use Apache::Reload with a threaded MPM and multiple interpreters,
the modules will be reloaded by each interpreter as they are used, not
every interpreter all at once. similar to 1.x where each child has
its own interpreter, the modules are reloaded as each kid is hit with a
request
Sreeji K Das wrote:
> Hi Stas,
>
>
>>>I was wondering if there is a possibility to
>>
>>reload PERL module compiled
>>
>>>into Apache
>>>with Apache::Registry
>>>(and I want to reload this module in all Apache
>>
>&g
Hi Stas,
> > I was wondering if there is a possibility to
> reload PERL module compiled
> > into Apache
> > with Apache::Registry
> > (and I want to reload this module in all Apache
> children processes) by running reload-program once.
>
> Currently Apache
Waldek Grudzien wrote:
> Hello,
>
> I was wondering if there is a possibility to reload PERL module compiled
> into Apache
> with Apache::Registry
> (and I want to reload this module in all Apache children processes) by
> running reload-program once.
>
> For example
Hello,
I was wondering if there is a possibility to reload PERL module compiled
into Apache
with Apache::Registry
(and I want to reload this module in all Apache children processes) by
running reload-program once.
For example Apache::Reload must be set as PerlInitHandler, so it's ha
Can Apache::Reload be used to reload modules that are "use"-d by httpd PerlModule,
PerlRequire, or PerlHandler directives, or do they have to be explicitly "use"-d in
code that is inside a handler? I think the answer is "yes - these are no different
than anythin
James wrote:
> Thus spake Christoph Lange ([EMAIL PROTECTED]):
>
>
>>I am using "use Apache::Reload;" in a module but it does not work. I tell
>>my "main"-script where to find this module via "use lib
>>'/home/path/for/modules'&quo
Thus spake Christoph Lange ([EMAIL PROTECTED]):
> I am using "use Apache::Reload;" in a module but it does not work. I tell
> my "main"-script where to find this module via "use lib
> '/home/path/for/modules'". Might this be the (or one) reason
Hi,
I am using "use Apache::Reload;" in a module but it
does not work. I tell my "main"-script where to find this module via "use lib
'/home/path/for/modules'". Might this be the (or one) reason why Apache::Reload
does not work?
Do I have to add
On Thu, 2 Aug 2001, Sidharth Malhotra wrote:
> In the Apache::Reload module, if the 'require' fails, your script bails out,
> and your client gets status 500. The side effect is that totally unrelated
> scripts can fail because a bad programmer on another end of the s
On Thu, 2 Aug 2001, Sidharth Malhotra wrote:
SM> In the Apache::Reload module, if the 'require' fails, your script
SM> bails out, and your client gets status 500. The side effect is
SM> that totally unrelated scripts can fail because a bad programmer
SM> on another end of
> However, now my logs are loaded with a ton of subroutine redefined
warnings
> (which is normal I suppose?). I can certainly live with this in a
> development environment, but thought I would check to see if it is
expected,
> and if it can be turned off while still enabling R
Of
Bryan Coon
Sent: Wednesday, August 01, 2001 9:36 AM
To: '[EMAIL PROTECTED]'
Subject: One more small Apache::Reload question
First, thanks to all the great suggestions, it looks like it works fine.
However, now my logs are loaded with a ton of subroutine redefined warnings
(which i
,
and if it can be turned off while still enabling Reload.
Thanks!
Bryan
yproject:
>
> use lib qw(/home/stas/myproject);
> require MyTest;
>
> Apache::Reload won't find this file, unless you alter @INC in
> startup.pl:
>
> startup.pl
> --
> use lib qw(/home/stas/myproject);
>
> and restart the server
Re: Apache::Reload???
On Tue, 31 Jul 2001, Bryan Coon wrote:
> I must have missed something in setting up Apache::Reload. What I want is
> simple that when I make a change in my scripts I dont have to restart the
> Apache server...
> I put
> PerlInitHandler Apache::Reload
> in m
On Tue, 31 Jul 2001, Philip Mak wrote:
> On Tue, 31 Jul 2001, Kyle Oppenheim wrote:
>
> > Apache::Reload works by performing a stat on every file in %INC and calling
> > require for all the files that changed. It's quite possible that some of
> > the files in
On Tue, 31 Jul 2001, Bryan Coon wrote:
> I must have missed something in setting up Apache::Reload. What I want is
> simple that when I make a change in my scripts I dont have to restart the
> Apache server...
> I put
> PerlInitHandler Apache::Reload
> in my httpd.conf, and
>-Original Message-
>From: Kyle Oppenheim
>To: [EMAIL PROTECTED]
>Sent: 7/31/01 10:01 PM
>Subject: RE: Apache::Reload???
>Apache::Reload works by performing a stat on every file in %INC and
>calling
>require for all the files that changed. It's quite poss
On Tue, 31 Jul 2001, Kyle Oppenheim wrote:
> Apache::Reload works by performing a stat on every file in %INC and calling
> require for all the files that changed. It's quite possible that some of
> the files in %INC are using relative paths (often '.' is in @INC). So,
Apache::Reload works by performing a stat on every file in %INC and calling
require for all the files that changed. It's quite possible that some of
the files in %INC are using relative paths (often '.' is in @INC). So, Perl
was able to load the file originally because the i
I must have missed something in setting up Apache::Reload. What I want is
simple that when I make a change in my scripts I dont have to restart the
Apache server...
I put
PerlInitHandler Apache::Reload
in my httpd.conf, and added 'use Apache::Reload' to the modules that I want
to be r
--On 30/07/01 06:43 -0400 Philip Mak wrote:
> In "perldoc Apache::Reload", the DESCRIPTION has the following sections:
>
> - StatINC Replacement
> - Register Modules Implicitly
> - Register Modules Explicitly
> - Special "Touch" File
>
> I just
covered in SYNOPSIS.
In "perldoc Apache::Reload", the DESCRIPTION has the following sections:
- StatINC Replacement
- Register Modules Implicitly
- Register Modules Explicitly
- Special "Touch" File
I just re-read it again and realized that "StatINC Replacement" i
1 - 100 of 174 matches
Mail list logo
