You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Matt Sergeant <ma...@sergeant.org> on 2000/08/31 11:22:48 UTC
Apache::Reload
Is there any interest in incorporating Apache::Reload into mod_perl
core? It seems to offer much more than StatINC, and in only a tiny bit
more code... (I'm not suggesting that this opens any floodgates for other
little modules incorporated into mod_perl, but this one seems globally
applicable, rather than limited to any particular domain).
--
<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 | AxKit: http://axkit.org
Re: Apache::Reload
Posted by Ask Bjoern Hansen <as...@valueclick.com>.
On Thu, 31 Aug 2000, Matt Sergeant wrote:
> Is there any interest in incorporating Apache::Reload into mod_perl
> core? It seems to offer much more than StatINC, and in only a tiny bit
> more code... (I'm not suggesting that this opens any floodgates for other
> little modules incorporated into mod_perl, but this one seems globally
> applicable, rather than limited to any particular domain).
I was going to ask you if you would mind doing exactly that. (And I
would change Apache::StatINC to just be a wrapper for ::Reload).
- ask
--
ask bjoern hansen - <http://www.netcetera.dk/~ask/>
more than 70M impressions per day, <http://valueclick.com>
Re: Apache::Reload
Posted by Matt Sergeant <ma...@sergeant.org>.
On 31 Aug 2000, (Randal L. Schwartz) wrote:
> >>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
>
> Matt> Ugh... Well I don't mind too much, but I'd prefer if someone else did the
> Matt> import and submission of patches - I'll just supply diffs if
> Matt> necessary. But if it has to be that way then so be it.
>
> As long as you're making a diff, can you spell my name right? :)
Already did for 0.04:
[matt@ted Apache-Reload]$ cvs log -r1.9 Reload.pm
RCS file: /home/cvs/Apache-Reload/Reload.pm,v
Working file: Reload.pm
head: 1.9
branch:
locks: strict
access list:
symbolic names:
matt: 1.1.1.1
fastnet: 1.1.1
keyword substitution: kv
total revisions: 10; selected revisions: 1
description:
----------------------------
revision 1.9
date: 2000/08/30 10:57:33; author: matt; state: Exp; lines: +4 -4
Spelling of Randal corrected
=============================================================================
--
<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 | AxKit: http://axkit.org
Re: Apache::Reload
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
Matt> Ugh... Well I don't mind too much, but I'd prefer if someone else did the
Matt> import and submission of patches - I'll just supply diffs if
Matt> necessary. But if it has to be that way then so be it.
As long as you're making a diff, can you spell my name right? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Apache::Reload
Posted by Gerald Richter <ri...@ecos.de>.
> > PerlSetVar ReloadModuleX <perl-regex>
>
> I already added something similar, only I didn't see the point in adding
> in regex support, so I just allow you to say:
>
> PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::*"
>
Yes, my patch is against 0.04 which already contains ReloadModules, but for
example I have a project called symphony, which consists of serval modules,
in different files, but all starting with symphony::, now I just can say
PerlSetVar ReloadModulesX ^symphony
and all modules belonging to this projects gets reloaded, otherwise I have
to say
PerlSetVar ReloadModules "symphony::foo symphony::bar symphony::config ....
"
and I have to keep track when a new module is added to add it to this list
also.
Actualy I just made a copy of your code for ReloadModules and modified it a
little bit
Gerald
Re: Apache::Reload
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sun, 3 Sep 2000, Ask Bjoern Hansen wrote:
> On Sun, 3 Sep 2000, Matt Sergeant wrote:
>
> > > I append a patch that let you say
> > >
> > > PerlSetVar ReloadModuleX <perl-regex>
> >
> > I already added something similar, only I didn't see the point in adding
> > in regex support, so I just allow you to say:
> >
> > PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::*"
>
> I find regex support useful. Regex'es allow for your syntax, but not
> the other way, so why not do it the most flexible way?
I just didn't see a use for the power of regexps here. And I consider them
too ugly to be adding to configuration files. And I don't consider
flexible to be the ultimate best solution. One thing I am considering
though is adding support for exclusion, like do My::*, but not
My::Bar. I'll work something out maybe later.
--
<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 | AxKit: http://axkit.org
Re: Apache::Reload
Posted by Ask Bjoern Hansen <as...@valueclick.com>.
On Sun, 3 Sep 2000, Matt Sergeant wrote:
> > I append a patch that let you say
> >
> > PerlSetVar ReloadModuleX <perl-regex>
>
> I already added something similar, only I didn't see the point in adding
> in regex support, so I just allow you to say:
>
> PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::*"
I find regex support useful. Regex'es allow for your syntax, but not
the other way, so why not do it the most flexible way?
- ask
--
ask bjoern hansen - <http://www.netcetera.dk/~ask/>
more than 70M impressions per day, <http://valueclick.com>
Re: Apache::Reload
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sun, 3 Sep 2000, Gerald Richter wrote:
>
> >
> > One thing I'd like to add,
> > and I'll send a patch to you soonish if you think it's worthwhile, is
> > the ability to specify a whole subtree to be reloaded: using ReloadModules
> > is fine but after a while adding modules to the list gets tedious. In most
> > cases I want to reload my application modules, and no others.
> >
>
> I append a patch that let you say
>
> PerlSetVar ReloadModuleX <perl-regex>
I already added something similar, only I didn't see the point in adding
in regex support, so I just allow you to say:
PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::*"
> P.S: The current version doesn't works with modules that uses pseudo hashs
> (with "use fields qw{ .. }" ). I already solved this problem, but I have to
> integrate it into Apache::Reload. When I have done it, I send a patch
Thanks - that would be great.
--
<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 | AxKit: http://axkit.org
Re: Apache::Reload
Posted by Gerald Richter <ri...@ecos.de>.
>
> One thing I'd like to add,
> and I'll send a patch to you soonish if you think it's worthwhile, is
> the ability to specify a whole subtree to be reloaded: using ReloadModules
> is fine but after a while adding modules to the list gets tedious. In most
> cases I want to reload my application modules, and no others.
>
I append a patch that let you say
PerlSetVar ReloadModuleX <perl-regex>
which allows you to specify a regex to reload modules. For example
PerlSetVar ReloadModuleX ^Apache
will check all Apache modules. Note: You have to use the / instead of the ::
as package separator if you need any.
PerlSetVar ReloadModuleX ^Apache/Auth
will realod all modules starting with Apache::Auth
I didn't have written the docs, Matt if you find this patch usefull maybe
you can do it (since your english is much better then mine :-), or drop me a
note and I will do it.
Gerald
P.S: The current version doesn't works with modules that uses pseudo hashs
(with "use fields qw{ .. }" ). I already solved this problem, but I have to
integrate it into Apache::Reload. When I have done it, I send a patch
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: Apache::Reload
Posted by Eric Cholet <ch...@logilune.com>.
> On Thu, 31 Aug 2000, Stas Bekman wrote:
>
> > > Is there any interest in incorporating Apache::Reload into mod_perl
> > > core? It seems to offer much more than StatINC, and in only a tiny bit
> > > more code... (I'm not suggesting that this opens any floodgates for other
> > > little modules incorporated into mod_perl, but this one seems globally
> > > applicable, rather than limited to any particular domain).
> >
> > Sounds nice to me. I'd give it a few more days to be tested before
> > releasing it in the mainstream since as you can see a few bugs were
> > spotted, so let's wait before it's polished out. I'm all for innovations,
> > just trying to be cautious you know.
>
> Understood. I believe your co-worker is playing with it as I type :-)
That's right... and it's working just great. One thing I'd like to add,
and I'll send a patch to you soonish if you think it's worthwhile, is
the ability to specify a whole subtree to be reloaded: using ReloadModules
is fine but after a while adding modules to the list gets tedious. In most
cases I want to reload my application modules, and no others.
>
> > It also depends on when Doug is planning the release of the next version.
> > If it's far away I guess we can put it into the cvs version now, so people
> > will have time to test it.
> >
> > BTW, Matt, you will need a CVS write access then, since if something
> > should be patched you can't do it without the access. You will have to ask
> > Doug to ask Brian to give it to you.
>
> Ugh... Well I don't mind too much, but I'd prefer if someone else did the
> import and submission of patches - I'll just supply diffs if
> necessary. But if it has to be that way then so be it.
I volunteer to do that, since I've already played with the code and sent you
patches :-)
--
Eric
Re: Apache::Reload
Posted by Stas Bekman <st...@stason.org>.
On Thu, 31 Aug 2000, Matt Sergeant wrote:
> On Thu, 31 Aug 2000, Stas Bekman wrote:
>
> > > Is there any interest in incorporating Apache::Reload into mod_perl
> > > core? It seems to offer much more than StatINC, and in only a tiny bit
> > > more code... (I'm not suggesting that this opens any floodgates for other
> > > little modules incorporated into mod_perl, but this one seems globally
> > > applicable, rather than limited to any particular domain).
> >
> > Sounds nice to me. I'd give it a few more days to be tested before
> > releasing it in the mainstream since as you can see a few bugs were
> > spotted, so let's wait before it's polished out. I'm all for innovations,
> > just trying to be cautious you know.
>
> Understood. I believe your co-worker is playing with it as I type :-)
Yup :)
> > It also depends on when Doug is planning the release of the next version.
> > If it's far away I guess we can put it into the cvs version now, so people
> > will have time to test it.
> >
> > BTW, Matt, you will need a CVS write access then, since if something
> > should be patched you can't do it without the access. You will have to ask
> > Doug to ask Brian to give it to you.
>
> Ugh... Well I don't mind too much, but I'd prefer if someone else did the
> import and submission of patches - I'll just supply diffs if
> necessary. But if it has to be that way then so be it.
Well, since Eric has volunteered for this position, I guess no problem
then. I just thought you'd get the chance to get the sought-after mod_perl
cvs write permissions :)
> > Also it means that you will have to withdraw the package from CPAN,
> > otherwise people will be confused. You will have to ask Andreas to delete
> > the last (and all) versions from CPAN. It's not a problem to delete the
> > packages from CPAN, you will be asked by one of the CPAN maintainers why
> > you are destroying the package (just letting you know the procedures :)
>
> You can do this from the web interface, providing you haven't actually
> registered the module with CPAN (i.e. listed in the CPAN module list),
> which I haven't.
Sure I know that, I've deleted lots of them :) I was talking about
deletion of the last version.
> However I don't see a point in removing it from CPAN - that enables people
> to use it in older mod_perl installations. What I can/will do is check
> $mod_perl::VERSION or $Apache::Reload::VERSION on install to ensure its
> not already there.
If you do that -- fine with me, still you will have to maintain two
versions, which is a mess. I'd leave the last release on CPAN (or a few
versions later, and have a note there that all the new versions are to be
found in the mod_perl core... But of course YMMV :)
> > Also what about the back compatibility with StatINC -- do you plan to keep
> > StatINC in the core mod_perl for a while and remove it for 2.0?
>
> Like Ask said - its a drop-in replacement, so we could just make StatINC a
> bunch of aliases for Reload methods.
That sounds good. The moment you do that, I'll demolish all the references
to StatINC in the guide and replace with Reload :) It's impornant to get
the right thing into the upcoming book as well.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Apache::Reload
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 31 Aug 2000, Stas Bekman wrote:
> > Is there any interest in incorporating Apache::Reload into mod_perl
> > core? It seems to offer much more than StatINC, and in only a tiny bit
> > more code... (I'm not suggesting that this opens any floodgates for other
> > little modules incorporated into mod_perl, but this one seems globally
> > applicable, rather than limited to any particular domain).
>
> Sounds nice to me. I'd give it a few more days to be tested before
> releasing it in the mainstream since as you can see a few bugs were
> spotted, so let's wait before it's polished out. I'm all for innovations,
> just trying to be cautious you know.
Understood. I believe your co-worker is playing with it as I type :-)
> It also depends on when Doug is planning the release of the next version.
> If it's far away I guess we can put it into the cvs version now, so people
> will have time to test it.
>
> BTW, Matt, you will need a CVS write access then, since if something
> should be patched you can't do it without the access. You will have to ask
> Doug to ask Brian to give it to you.
Ugh... Well I don't mind too much, but I'd prefer if someone else did the
import and submission of patches - I'll just supply diffs if
necessary. But if it has to be that way then so be it.
> Also it means that you will have to withdraw the package from CPAN,
> otherwise people will be confused. You will have to ask Andreas to delete
> the last (and all) versions from CPAN. It's not a problem to delete the
> packages from CPAN, you will be asked by one of the CPAN maintainers why
> you are destroying the package (just letting you know the procedures :)
You can do this from the web interface, providing you haven't actually
registered the module with CPAN (i.e. listed in the CPAN module list),
which I haven't.
However I don't see a point in removing it from CPAN - that enables people
to use it in older mod_perl installations. What I can/will do is check
$mod_perl::VERSION or $Apache::Reload::VERSION on install to ensure its
not already there.
> Also what about the back compatibility with StatINC -- do you plan to keep
> StatINC in the core mod_perl for a while and remove it for 2.0?
Like Ask said - its a drop-in replacement, so we could just make StatINC a
bunch of aliases for Reload methods.
--
<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 | AxKit: http://axkit.org
Re: Apache::Reload
Posted by Stas Bekman <st...@stason.org>.
> Is there any interest in incorporating Apache::Reload into mod_perl
> core? It seems to offer much more than StatINC, and in only a tiny bit
> more code... (I'm not suggesting that this opens any floodgates for other
> little modules incorporated into mod_perl, but this one seems globally
> applicable, rather than limited to any particular domain).
Sounds nice to me. I'd give it a few more days to be tested before
releasing it in the mainstream since as you can see a few bugs were
spotted, so let's wait before it's polished out. I'm all for innovations,
just trying to be cautious you know.
It also depends on when Doug is planning the release of the next version.
If it's far away I guess we can put it into the cvs version now, so people
will have time to test it.
BTW, Matt, you will need a CVS write access then, since if something
should be patched you can't do it without the access. You will have to ask
Doug to ask Brian to give it to you.
Also it means that you will have to withdraw the package from CPAN,
otherwise people will be confused. You will have to ask Andreas to delete
the last (and all) versions from CPAN. It's not a problem to delete the
packages from CPAN, you will be asked by one of the CPAN maintainers why
you are destroying the package (just letting you know the procedures :)
Also what about the back compatibility with StatINC -- do you plan to keep
StatINC in the core mod_perl for a while and remove it for 2.0?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org