You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/05/20 15:32:24 UTC
removing PerlLoadModule directive handler requirement
hi all...
I'd like to suggest that we remove the requirement that modules loaded with
PerlLoadModule need to have directive handler support.
now that PerlModule defers init processing until after the interpreter has started,
there is currently now way to force an early interpreter invocation for actions that are
required on startup. for instance, in addition to directive handler support, the new aaa
ap_register_provider hook needs to be called at startup before the authen modules see the
Auth*Provider statements in httpd.conf (otherwise the server won't start). so, if I want
my Perl module to register a provider, I don't have any way to get the call in early
enough unless I provide some dummy directive handlers (well, I can force some <Perl>
sections in there to trick the early interpreter, but :)
anyway, I'm suggesting that PerlLoadModule be available to all handlers that require an
interpreter be created early, not merely directive handlers. the below patch is simple
enough and does the trick. all tests pass for me.
--Geoff
Index: src/modules/perl/modperl_module.c
===================================================================
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_module.c,v
retrieving revision 1.13
diff -u -r1.13 modperl_module.c
--- src/modules/perl/modperl_module.c 12 May 2003 13:00:15 -0000 1.13
+++ src/modules/perl/modperl_module.c 20 May 2003 13:09:19 -0000
@@ -636,8 +636,7 @@
#endif
if (!(module_cmds = modperl_module_cmds_get(aTHX_ modp))) {
- return apr_pstrcat(p, "module ", modp->name,
- " does not define @APACHE_MODULE_COMMANDS", NULL);
+ return NULL;
}
fill = AvFILL(module_cmds);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> >> not exactly. I think it's fine in most cases to have PerlModule behave
> >> as it does now. it's in the exceptional cases that the problem
> >> resides.
> >
> >
> > Actually it's not fine now. Consider:
>
> > PerlRequire /path/to/startup.pl
> >
> > As the current implementation goes we have a problem, because it won't
> > work unless something (<Perl> or PerlLoadModule) has triggered a perl
> > startup and the startup.pl file was actually required during the config
> > phase.
>
> oops :)
>
> >
> > So what I'm saying that your issue is not the only one that requires an
> > early perl startup. So may be the problem is more global and solving it
> > will automatically resolve your issue, without any heavy patching.
>
> as I had originally though about it, I figured the issue would only reside
> with modules. but, as you pointed out, config changes in startup.pl
> will have issues too. hmph.
>
> personally, I can't see many people using add_config from a startup.pl -
> if they can add a startup.pl they can add the config themselves (except
> for maybe the tests :). more typically, I would expect add_config() to
> be called from modules as to add config settings silently.
> Apache::WinBitHack is a good example - it overrides XBitHack but (in
> mp1) still needs to add a PerlFixupHandler to function properly. in mp2
> it would just override XBitHack and silently add the fixup handler via
> add_config(). doug's illustration of using it to add require directives
> I suspect will also be a common use.
In that case we need to at least fix PerlLoadModule to call ap_add_module only
if module directives are defined. I still don't like using this interface for
its side effects.
If we get this functionality in place, we also will need to provide developers
a hint how to check whether the module wasn't loaded after the config phase.
Perhaps a simple call to Apache::current_callback will do. Or may be it won't
help much, as things will fail if not started in time.
> are there other config situations other than add_config() that you can
> think of? I still think it's valid to delay interpreter start and have
> PerlModule behave as it does now (provided we have an alternative :),
> but as the number of exceptional cases rise, it makes less and less sense.
Nothing comes to my mind but it's possible that there are others, or there
will be others later on.
BTW, one other reason for postponing startup is to be able to specify
PerlSwitches anywhere in the config file and PerlInterp* directives as well
(as Doug has reminded me). Something that won't work after perl was started.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> not exactly. I think it's fine in most cases to have PerlModule behave
>> as it does now. it's in the exceptional cases that the problem
>> resides.
>
>
> Actually it's not fine now. Consider:
> PerlRequire /path/to/startup.pl
>
> As the current implementation goes we have a problem, because it won't
> work unless something (<Perl> or PerlLoadModule) has triggered a perl
> startup and the startup.pl file was actually required during the config
> phase.
oops :)
>
> So what I'm saying that your issue is not the only one that requires an
> early perl startup. So may be the problem is more global and solving it
> will automatically resolve your issue, without any heavy patching.
as I had originally though about it, I figured the issue would only reside
with modules. but, as you pointed out, config changes in startup.pl will
have issues too. hmph.
personally, I can't see many people using add_config from a startup.pl - if
they can add a startup.pl they can add the config themselves (except for
maybe the tests :). more typically, I would expect add_config() to be
called from modules as to add config settings silently. Apache::WinBitHack
is a good example - it overrides XBitHack but (in mp1) still needs to add a
PerlFixupHandler to function properly. in mp2 it would just override
XBitHack and silently add the fixup handler via add_config(). doug's
illustration of using it to add require directives I suspect will also be a
common use.
are there other config situations other than add_config() that you can think
of? I still think it's valid to delay interpreter start and have PerlModule
behave as it does now (provided we have an alternative :), but as the number
of exceptional cases rise, it makes less and less sense.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Stas Bekman <st...@stason.org>.
Before I address the branch of thought you are taking what do you say about this:
>> Basically all you want is for mp2 to behave the same as mp1, i.e.
>> start immediately and having PerlModule, PerlRequire do their job
>> right away.
>
>
> not exactly. I think it's fine in most cases to have PerlModule behave
> as it does now. it's in the exceptional cases that the problem resides.
Actually it's not fine now. Consider:
startup.pl:
-----------
my $conf = <<'EOC';
# must use PerlModule here to check for segfaults
PerlModule Apache::TestHandler
<Location /apache/add_config>
SetHandler perl-script
PerlResponseHandler Apache::TestHandler::ok1
</Location>
EOC
Apache->server->add_config([split /\n/, $conf]);
httpd.conf:
-----------
PerlRequire /path/to/startup.pl
As the current implementation goes we have a problem, because it won't work
unless something (<Perl> or PerlLoadModule) has triggered a perl startup and
the startup.pl file was actually required during the config phase.
So what I'm saying that your issue is not the only one that requires an early
perl startup. So may be the problem is more global and solving it will
automatically resolve your issue, without any heavy patching.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Basically all you want is for mp2 to behave the same as mp1, i.e. start
> immediately and having PerlModule, PerlRequire do their job right away.
not exactly. I think it's fine in most cases to have PerlModule behave as
it does now. it's in the exceptional cases that the problem resides.
>
> You have found that PerlLoadModule accomplish that, but I urge you to
> look at the code that implements that. You will see that you don't want
> to run PerlLoadModule just to start perl.
the idea for PerlLoadModule was born out of necessity - PerlModule was
insufficient for directive handlers because directive handlers need to run
perl at config. so the problem isn't with PerlLoadModule, but rather it's
implementation. I think it should me made more generic and not just apply
to directive handlers because there are other things modules might need to
happen at config time.
but yes, currently there is more to PerlLoadModule than I require. but I
think that probably can be abstracted away somewhat so that PerlLoadModule
be made generic and directive handlers still require PerlLoadModule. it is
a lot of work, though :)
>> the issue is that some modules require activity during startup/config,
>> and thus require Perl to be running. adding PerlStartNow means that
>> modules cannot rely on only themselves to work - they require even
>> more outside intervention in the form of additional directives to even
>> load properly. yucko.
>
>
> Good point. So we are falling back to the need to start perl as early as
> possible. But let's not take the goodness of being able to postpone
> things away.
the need is isolated.
in mp1 directive handlers require PerlModule - use() from startup.pl is
insufficient, even though it suffices for loading most other modules. I'm
suggesting that we follow that same pattern with PerlLoadModule - in some
cases (which module authors will know and decide) activity will need to
happen at config time, for the majority of others it will be sufficient to
use PerlModule.
>> I don't think we need that either. it does make some sense to delay
>> perl until it's needed. it's just that for some things it's needed at
>> config.
>
>
> But that's what I'm proposing. Let the user decide what they want.
actually, it's the module author I'm concerned with, not the user. "by the
way, if you want this module to work you'll need to start perl early"
doesn't make much sense to users, and I still think early is a misnomer.
the better way (I'm convinced) is to abstract away the notion of the
interpreter and say to module authors "if you require LoadModule behavior,
such as per-module initializations that need to occur during configuration,
use require PerlLoadModule. if you can live with your module being loaded
on demand, suggest PerlModule instead"
> So we add:
>
> PerlPostponeStart - use this directive as a very first perl directive in
> httpd.conf if you know that none of the modules that you load needs to
> be run during the configuration phase. This will speedup the startup
> process.
this makes the issue more about tweaking the server than it addresses the
needs of individual modules.
anyway, this is probably something else for us to discuss at OSCon. I doubt
I'll be able to do anything here but complain over the next few months.
>
> BTW, Geoff have you seen how long does it take to start threaded mpm
> mod_perl test suite?
everything on my P233 is slow :)
anyway, time for sleep.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> Don't you
>> think it's a bad design, if all you want is to trigger the perl
>> startup early?
>
>
> no :)
>
> because that's not all I want to do. what I want is to have my code run
> during the config phase, and that happens to require that Perl be
> running. see, it's not early if I require it - it's only early if it's
> started for no reason :)
Basically all you want is for mp2 to behave the same as mp1, i.e. start
immediately and having PerlModule, PerlRequire do their job right away.
You have found that PerlLoadModule accomplish that, but I urge you to look at
the code that implements that. You will see that you don't want to run
PerlLoadModule just to start perl.
>> If perl is not started during the config phase, all directives
>> like PerlModule and PerlRequire are postponed till after the config
>> phase. If you wish to force those to run immediately during the config
>> phase, you can turn on the early perl startup using the PerlStartNow
>> directive.
>
>
> the issue is that some modules require activity during startup/config,
> and thus require Perl to be running. adding PerlStartNow means that
> modules cannot rely on only themselves to work - they require even more
> outside intervention in the form of additional directives to even load
> properly. yucko.
Good point. So we are falling back to the need to start perl as early as
possible. But let's not take the goodness of being able to postpone things away.
>> now we just need to implement this simple directive.
>
>
> I don't see the reason for this - you can always just insert a no-op
> within <Perl>. the effect I want is the ability for module loading to
> be more DWIMmy.
Agreed.
>> BTW, as I think about it, since the startup file execution is normally
>> postponed, it's impossible to change the config via $s->add_config. So
>> this is another case where perl must be started early.
>>
>> Alternatively we can take a more intuitive direction (mp1-like):
>> always start perl as soon as mod_perl.so is loaded. Have a directive
>> that will try to postpone the startup of perl.
>
>
> I don't think we need that either. it does make some sense to delay
> perl until it's needed. it's just that for some things it's needed at
> config.
But that's what I'm proposing. Let the user decide what they want. For most
users the default start-perl-immediately will work just fine (and will be
DWIMish). Others who know that they don't need to start perl early and want to
make things faster at the startup, will have the tool to make this happen.
So we add:
PerlPostponeStart - use this directive as a very first perl directive in
httpd.conf if you know that none of the modules that you load needs to be run
during the configuration phase. This will speedup the startup process.
BTW, Geoff have you seen how long does it take to start threaded mpm mod_perl
test suite? It's about 30-45 secs on my Dual CPU box. And perl is at fault
here I think. So if you can shorten this time, it's a good thing. I think this
has to do with loading DSOs. Once we have a static build we will be able to
compare more.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Don't you
> think it's a bad design, if all you want is to trigger the perl startup
> early?
no :)
because that's not all I want to do. what I want is to have my code run
during the config phase, and that happens to require that Perl be running.
see, it's not early if I require it - it's only early if it's started for no
reason :)
> If perl is not started during the config phase, all directives
> like PerlModule and PerlRequire are postponed till after the config
> phase. If you wish to force those to run immediately during the config
> phase, you can turn on the early perl startup using the PerlStartNow
> directive.
the issue is that some modules require activity during startup/config, and
thus require Perl to be running. adding PerlStartNow means that modules
cannot rely on only themselves to work - they require even more outside
intervention in the form of additional directives to even load properly. yucko.
>
> now we just need to implement this simple directive.
I don't see the reason for this - you can always just insert a no-op within
<Perl>. the effect I want is the ability for module loading to be more DWIMmy.
>
> BTW, as I think about it, since the startup file execution is normally
> postponed, it's impossible to change the config via $s->add_config. So
> this is another case where perl must be started early.
>
> Alternatively we can take a more intuitive direction (mp1-like): always
> start perl as soon as mod_perl.so is loaded. Have a directive that will
> try to postpone the startup of perl.
I don't think we need that either. it does make some sense to delay perl
until it's needed. it's just that for some things it's needed at config.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> well, I guess we disagree then. personally, I think the wrong part is
> using PerlLoadModule for _only_ directive handlers, when all kinds of
> other stuff can be coded/required to happen when a module is loaded.
We do agree that we need this functionality. All I'm telling you is that
PerlLoadModule is not the right place, as it is implemented now, because it
goes to the pains of registering a new module with Apache. Don't you think
it's a bad design, if all you want is to trigger the perl startup early?
> but I'm not really in a position to rewrite a massive patch to fix it
> all, so I guess I'll keep quiet for now.
There is no need to write a massive patch, neither being quiet. My suggestion
is very simple:
In mod_perl 2.0 perl starting is deferred until after config phase has been
completed (meaning that it'll start only after Apache restarts itself).
However there are several directives, such as <Perl> sections and
PerlLoadModule that will trigger a perl start during the config phase. If perl
is not started during the config phase, all directives like PerlModule and
PerlRequire are postponed till after the config phase. If you wish to force
those to run immediately during the config phase, you can turn on the early
perl startup using the PerlStartNow directive.
now we just need to implement this simple directive.
BTW, as I think about it, since the startup file execution is normally
postponed, it's impossible to change the config via $s->add_config. So this is
another case where perl must be started early.
Alternatively we can take a more intuitive direction (mp1-like): always start
perl as soon as mod_perl.so is loaded. Have a directive that will try to
postpone the startup of perl.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>
>>> You know, it seems that PerlLoadModule is a misleading name. It
>>> suggests that its purpose is to load a module.
>>
>>
>>
>> well, in some sense it does - it's the Perl equivalent of LoadModule
>> which, in part, populates the module record and makes it possible to
>> handle directives. the problem, I think, is in having the code for
>> PerlLoadModule so specific to directive handlers - there are clearly
>> other reasons you might want to invoke Perl early, so limiting that
>> behavior to directive handlers doesn't seem right.
>
>
> But you just said by yourself that it's mnemonic to LoadModule, not
> starting perl.
yes. but in Apache, loading a module runs the module init (at least it did in 1.3) - when
I load a Perl module I want stuff to run too. the fact that Perl is started "early" is
irrelevant - to me, PerlLoadModule should load the module in a Perl sense, which means
running import() and other stuff immediately, the same as what happens when Perl loads a
module via use() (eg, it's not deferred until later). the deferred status of PerlModule is
really more like module "registering" than it used to be (remember, the old explanation
was that PerlModule was like use() and PerlRequire like require(), which is now no longer
strictly true, since the real use() doesn't happen immediately when the use() is seen).
> Obviously we need to do something to do the init stuff. But doing it in
> PerlLoadModule is simply wrong, even though it happens to work. Look at
> the implementation and you will see why (e.g. you don't want to register
> a new module, just because you want to start perl early).
>
> I'd rather see a new directive PerlFooModule, which maps to PerlModule
> 1:1, but triggers an early startup. e.g. PerlModuleNow/PerlRequreNow
well, I guess we disagree then. personally, I think the wrong part is using
PerlLoadModule for _only_ directive handlers, when all kinds of other stuff can be
coded/required to happen when a module is loaded.
but I'm not really in a position to rewrite a massive patch to fix it all, so I guess I'll
keep quiet for now.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> You know, it seems that PerlLoadModule is a misleading name. It
>> suggests that its purpose is to load a module.
>
>
> well, in some sense it does - it's the Perl equivalent of LoadModule
> which, in part, populates the module record and makes it possible to
> handle directives. the problem, I think, is in having the code for
> PerlLoadModule so specific to directive handlers - there are clearly
> other reasons you might want to invoke Perl early, so limiting that
> behavior to directive handlers doesn't seem right.
But you just said by yourself that it's mnemonic to LoadModule, not starting perl.
> in thinking about it, I like the name, so long as it does actually load
> the module and make it possible to have the Perl equivalent of module
> init - calling post_config stuff, handling directives, registering
> providers, etc. in truth, I don't understand why PerlModule behaves the
> way it does now, but in changing behaviors between mp1 and mp2 you've
> lost the ability to do module init stuff.
mod_perl 2.0 tries to pospone the starting of perl, and if doesn't hit <Perl >
sections or PerlLoadModule will do that only in the open_logs phase (which
comes after the config, making the startup faster (remember that config phase
is running twice).
> I think what I'd like to see is the directive handler support stripped
> away from the PerlLoadModule implementation a bit, making PerlLoadModule
> equivalent to PerlModule except that PerlLoadModule starts perl on
> demand rather than when required. directive handlers would be noted to
> require PerlLoadModule, in much the same way as mp1 requires PerlModule
> over simple use() statements.
Obviously we need to do something to do the init stuff. But doing it in
PerlLoadModule is simply wrong, even though it happens to work. Look at the
implementation and you will see why (e.g. you don't want to register a new
module, just because you want to start perl early).
I'd rather see a new directive PerlFooModule, which maps to PerlModule 1:1,
but triggers an early startup. e.g. PerlModuleNow/PerlRequreNow
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> You know, it seems that PerlLoadModule is a misleading name. It suggests
> that its purpose is to load a module.
well, in some sense it does - it's the Perl equivalent of LoadModule which,
in part, populates the module record and makes it possible to handle
directives. the problem, I think, is in having the code for PerlLoadModule
so specific to directive handlers - there are clearly other reasons you
might want to invoke Perl early, so limiting that behavior to directive
handlers doesn't seem right.
in thinking about it, I like the name, so long as it does actually load the
module and make it possible to have the Perl equivalent of module init -
calling post_config stuff, handling directives, registering providers, etc.
in truth, I don't understand why PerlModule behaves the way it does now,
but in changing behaviors between mp1 and mp2 you've lost the ability to do
module init stuff.
I think what I'd like to see is the directive handler support stripped away
from the PerlLoadModule implementation a bit, making PerlLoadModule
equivalent to PerlModule except that PerlLoadModule starts perl on demand
rather than when required. directive handlers would be noted to require
PerlLoadModule, in much the same way as mp1 requires PerlModule over simple
use() statements.
well, that's my $0.02... and I know, patches welcome :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: removing PerlLoadModule directive handler requirement
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi all...
>
> I'd like to suggest that we remove the requirement that modules loaded
> with PerlLoadModule need to have directive handler support.
>
> now that PerlModule defers init processing until after the interpreter
> has started, there is currently now way to force an early interpreter
> invocation for actions that are required on startup. for instance, in
> addition to directive handler support, the new aaa ap_register_provider
> hook needs to be called at startup before the authen modules see the
> Auth*Provider statements in httpd.conf (otherwise the server won't
> start). so, if I want my Perl module to register a provider, I don't
> have any way to get the call in early enough unless I provide some dummy
> directive handlers (well, I can force some <Perl> sections in there to
> trick the early interpreter, but :)
>
> anyway, I'm suggesting that PerlLoadModule be available to all
> handlers that require an interpreter be created early, not merely
> directive handlers. the below patch is simple enough and does the
> trick. all tests pass for me.
You know, it seems that PerlLoadModule is a misleading name. It suggests that
its purpose is to load a module. It'd be much better off called
PerlDirectiveModule or something like that. Otherwise it fits your purpose ;)
Should we use a side-effect of an existing mechanism to do something else? May
be we need to have a special directive that will start perl early? PerlStartNow?
> Index: src/modules/perl/modperl_module.c
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_module.c,v
> retrieving revision 1.13
> diff -u -r1.13 modperl_module.c
> --- src/modules/perl/modperl_module.c 12 May 2003 13:00:15 -0000
> 1.13
> +++ src/modules/perl/modperl_module.c 20 May 2003 13:09:19 -0000
> @@ -636,8 +636,7 @@
> #endif
>
> if (!(module_cmds = modperl_module_cmds_get(aTHX_ modp))) {
> - return apr_pstrcat(p, "module ", modp->name,
> - " does not define @APACHE_MODULE_COMMANDS",
> NULL);
> + return NULL;
> }
>
> fill = AvFILL(module_cmds);
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org