You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Brent 'Dax' Royal-Gordon <br...@brentdax.com> on 2004/05/14 07:23:34 UTC
[mp2] Custom directives
Hello,
I'm writing a pure-Perl Apache 2 module that installs a few custom
directives. Four of the directives are only useful in the server root
(i.e. outside of any VirtualHost, Directory, etc. directives), but three
others make sense within containers.
The directives seem to parse correctly, but when I try to access the
configuration structure from a PostConfigHandler or ChildInitHandler,
the resulting structure contains the default configuration, as if the
directives had never been parsed at all. (I want a PostConfigHandler
because I need to fork off a single background process for the entire
server, and that seems like the easiest way to do so.)
At the very least, I'm looking for a good example of a module that does
something like this, but if someone can help me with the specific
problem I'm having, that'd be even better.
Some (possibly) relevant bits of code follow...
our @APACHE_MODULE_COMMANDS=(
{
name => 'RegulateDatabase',
args_how => Apache::TAKE123,
req_override => Apache::RSRC_CONF,
errmsg => 'RegulateDatabase connectionstring [username
[password]]'
},
...
);
sub SERVER_CREATE {
return bless {
Database => ['DBI:mysql:Regulate'],
...
}, shift;
}
sub DIR_CREATE {
return bless {
...
}, shift;
}
sub SERVER_MERGE {
my($base, $add)=@_;
return bless { %$add, %$base }, ref $base;
}
sub DIR_MERGE {
my($base, $add)=@_;
return bless { %$add, %$base }, ref $base;
}
sub RegulateDatabase {
my($self, $params, @args)=(@_);
$self->{Database}=\@args;
}
sub global_init #:PostConfigHandler
{
my(undef, undef, undef, $s)=@_;
my $conf=Apache::Module->get_config(__PACKAGE__, $s);
...
my $dbh=DBI->connect(@{$conf->{Database}}, {RaiseError=>1}) or
die $DBI::errstr;
}
Even with a line in my httpd.conf like:
PerlLoadModule Apache::Regulate
RegulateDatabase 'dbi:mysql:apache' apache [redacted]
global_init() dies with this error:
DBI connect('Regulate','HASH(0x8a377ec)',...) failed: Access denied
for user: '@localhost' to database 'Regulate'
Which leads me to believe that either the information isn't being
recorded for some reason, or I'm looking at the wrong $conf structure.
Any help, even just a pointer to a module that does something like this,
would be much appreciated. In the mean time, I guess I'll hardwire the
values I want and continue testing...
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: data sharing.
Posted by Jens Gassmann <je...@atomix.de>.
Hi Perrin, hi list,
sorry, my Template Module use it and so i think it could be so bad, but
i learn gladly in addition,
- Jens
Perrin Harkins wrote:
> On Tue, 2004-06-01 at 09:46, Jens Gassmann wrote:
>
>>maybe IPC-SharedCache helps you:
>>http://search.cpan.org/~samtregar/IPC-SharedCache-1.3/SharedCache.pm
>
>
> I guess maybe you missed the rating where the module's own author says
> not to use it.
>
> This is based on IPC::ShareLite, like several other IPC modules, and
> IPC::ShareLite is impractical for any significant amount of data. To
> store a hash of objects it would have to serialize the entire hash and
> stuff it into shared memory on every update, and then de-serialize the
> entire hash on the other side every time you want to read a key from it.
>
> This has all been discussed at great length and you can find it in the
> mailing list archives. The current winners on my benchmarks for local
> (i.e. not a cluster of machines) sharing are BerkeleyDB, IPC::MM, and
> Cache::FastMmap.
>
> - Perrin
>
--
Der Kopf ist rund, damit das Denken die Richtung ändern kann!
E-Mail: jens.gassmann@atomix.de
Internet: http://www.atomix.de/
Mobil: 0179/1361016
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: data sharing.
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-06-01 at 09:46, Jens Gassmann wrote:
> maybe IPC-SharedCache helps you:
> http://search.cpan.org/~samtregar/IPC-SharedCache-1.3/SharedCache.pm
I guess maybe you missed the rating where the module's own author says
not to use it.
This is based on IPC::ShareLite, like several other IPC modules, and
IPC::ShareLite is impractical for any significant amount of data. To
store a hash of objects it would have to serialize the entire hash and
stuff it into shared memory on every update, and then de-serialize the
entire hash on the other side every time you want to read a key from it.
This has all been discussed at great length and you can find it in the
mailing list archives. The current winners on my benchmarks for local
(i.e. not a cluster of machines) sharing are BerkeleyDB, IPC::MM, and
Cache::FastMmap.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: data sharing.
Posted by Jens Gassmann <je...@atomix.de>.
Hello Anthony,
maybe IPC-SharedCache helps you:
http://search.cpan.org/~samtregar/IPC-SharedCache-1.3/SharedCache.pm
Regards,
jens
--
"If the facts don't fit the theory, change the facts" Albert Einstein
EMail: jens.gassmann@atomix.de
Handy: 0179/136 10 16
Büro : 0221/975 08 20
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
data sharing.
Posted by Anthony Hinsinger <an...@univ-metz.fr>.
Hello,
I'd like to share a hash table between all apache processes (i'm using
apache 1.3.x and mod_perl 1.27)
Each process must be able to add and remove key/value in this hash
(values are perl blessed objects)
Does anyone has experiences with this kind of problem ?
Thanks
Anthony Hinsinger
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Hmm, have you by chance missed that I actually wrote the code that does
>>that in the message that this reply goes to? And as I show there, it
>>doesn't work. Please see my original (previous) post. thanks.
>
>
> sorry, I guess I was answering a different question. :)
:)
> I thought you were asking about the MPMQ_STATE query proper and if we could
> support the API across the board. whether the quI have no idea (versus
^^^^ ?
> starting and running), well I guess you've proven it doesn't, so I guess
> it's of no use to you for the issue at hand.
>
> but that's separate from whether we can support a state query with the next
> mp2 release, so that when httpd supports a real distinction people using a
> recent httpd can find out the info they need.
Well, it's supported already, the source scan has picked it and with a few
tweaks it's conditioned to work where available. We just don't advertise it
till it's supported by the minimal required Apache version.
Since MPMQ_STATE doesn't satisfy Brent's quest, I suggest not to worry about
it now.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Hmm, have you by chance missed that I actually wrote the code that does
> that in the message that this reply goes to? And as I show there, it
> doesn't work. Please see my original (previous) post. thanks.
sorry, I guess I was answering a different question. :)
I thought you were asking about the MPMQ_STATE query proper and if we could
support the API across the board. whether the quI have no idea (versus
starting and running), well I guess you've proven it doesn't, so I guess
it's of no use to you for the issue at hand.
but that's separate from whether we can support a state query with the next
mp2 release, so that when httpd supports a real distinction people using a
recent httpd can find out the info they need.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>They aren't yet available in mp2, mostly due to the fact
>>that they weren't available in the Apache API until recently, and from
>>what Geoff has mentioned it seems to be incomplete yet. Geoff, what's
>>the current status of these query flags? I wasn't following cvs commits
>>for quite some time. I've tried the new query flags added recently (you
>>need cvs modperl and cvs apache to get them):
>
>
> they appear to be in 2.0 HEAD (APACHE_2_0_BRANCH) for all mpms. I know that
> jeff started with worker and prefork, so if there are any gaps I would
> expect them to be elsewhere.
>
> FWIW, they also appear to be in 2.0.49, having been introduced in worker
> this past december. so it may not be long before we can officially support
> them, but it will be a while - we're currently supporting 2.0.46, and I'd
> suggest to move to 2.0.47 soonish, but 2.0.49 as the minimum is pretty far off.
Thanks Geoff.
We could provide our own flag meanwhile, using the pool user data trick. Or we
could expose the API to users, so they can do it in perl. It probably should
be a function and not a variable/constant, so that when Apache catches up and
provides such support we will internally switch to it.
> but perhaps we can work support in gradually. the way you get these is just
> by querying ap_mpm_query for a new state (AP_MPMQ_MPM_STATE). most (if not
> all) mpms return APR_ENOTIMPL for an unknown query, so if we simply provided
> the required constant definitions we could probably open it all up now - on
> platforms where it isn't supported Apache::MPM::query would just return
> APR::ENOTIMPL instead of Apache::MPMQ_STARTING.
Hmm, have you by chance missed that I actually wrote the code that does that
in the message that this reply goes to? And as I show there, it doesn't work.
Please see my original (previous) post. thanks.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> They aren't yet available in mp2, mostly due to the fact
> that they weren't available in the Apache API until recently, and from
> what Geoff has mentioned it seems to be incomplete yet. Geoff, what's
> the current status of these query flags? I wasn't following cvs commits
> for quite some time. I've tried the new query flags added recently (you
> need cvs modperl and cvs apache to get them):
they appear to be in 2.0 HEAD (APACHE_2_0_BRANCH) for all mpms. I know that
jeff started with worker and prefork, so if there are any gaps I would
expect them to be elsewhere.
FWIW, they also appear to be in 2.0.49, having been introduced in worker
this past december. so it may not be long before we can officially support
them, but it will be a while - we're currently supporting 2.0.46, and I'd
suggest to move to 2.0.47 soonish, but 2.0.49 as the minimum is pretty far off.
but perhaps we can work support in gradually. the way you get these is just
by querying ap_mpm_query for a new state (AP_MPMQ_MPM_STATE). most (if not
all) mpms return APR_ENOTIMPL for an unknown query, so if we simply provided
the required constant definitions we could probably open it all up now - on
platforms where it isn't supported Apache::MPM::query would just return
APR::ENOTIMPL instead of Apache::MPMQ_STARTING.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Apache start/restart nuances (was Re: [mp2] Custom directives)
Posted by Stas Bekman <st...@stason.org>.
Brent 'Dax' Royal-Gordon wrote:
> Stas Bekman wrote:
>
>>> a=SERVER_CREATE();
>>> b=SERVER_CREATE();
>>> RegulateDatabase(a, ...);
>>> global_init(b);
>>> global_init(c);
>>>
>>> I have no idea where 'c' is coming from--like I said, I've
>>> instrumented {SERVER,DIR}_{CREATE,MERGE}, which I think should cover
>>> everything.
>>
>>
>> PostConfig is called twice, because of the server startup:
>> http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_Phases_Demonstration_Module
>
>
>
> Right...I figured I could probably handle that by setting a flag
> variable somewhere, or something of the sort.
>
> Why are the PostConfig handlers being given config objects with
> different addresses, though?
>
> ...hmm. It looks like they're being handed different server objects:
> global_init server: Apache::Server=SCALAR(0x8caded0)
> global_init server: Apache::Server=SCALAR(0x8c059e0)
Because the second time it's a totally different perl. The perl that was used
during the startup is no more during the restart.
> Okay, this is starting to beg a question: why is PostConfig called
> twice? What does each call represent?
You probably need to read the section at the URL quoted above. If it's still
not clear, please tell us what.
> Why is it only called once for
> an 'apachectl -k restart'?
See the URL above. 'apachectl -k start' doing start and immediately restart.
> And perhaps the question I should've asked to start with: if I need to
> fork off one background process for the entire Apache server, what
> handler should I do so in?
Any phase before child_init is fine. Though you will have to deal with restart
calling this action again.
In mod_perl 1 there were $Server::Starting, Server::ReStarting flags which you
could check to decide whether to do something or not at the server startup.
They aren't yet available in mp2, mostly due to the fact that they weren't
available in the Apache API until recently, and from what Geoff has mentioned
it seems to be incomplete yet. Geoff, what's the current status of these query
flags? I wasn't following cvs commits for quite some time. I've tried the new
query flags added recently (you need cvs modperl and cvs apache to get them):
use Apache::MPM ();
use Apache::Const -compile => qw(OK :mpmq);
my %states = (
+Apache::MPMQ_STARTING => 'starting',
+Apache::MPMQ_RUNNING => 'running',
);
sub post_config {
my($conf_pool, $log_pool, $temp_pool, $s) = @_;
my $state = Apache::MPM->query(Apache::MPMQ_MPM_STATE);
warn "Apache server is $states{$state}\n";
Apache::OK;
}
But it prints 'starting' both on start and restart. I'd expect it to print
running (or restarting). So I suppose these query flags don't give us the
information we are after.
If nothing else works we will need to use the apr_pool user data trick and
provide flag variables similar to mp1.
So for now, Brent, please use some flag (e.g. lock file) to decide whether
you've already forked the process.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Brent 'Dax' Royal-Gordon <br...@brentdax.com>.
Stas Bekman wrote:
>> a=SERVER_CREATE();
>> b=SERVER_CREATE();
>> RegulateDatabase(a, ...);
>> global_init(b);
>> global_init(c);
>>
>> I have no idea where 'c' is coming from--like I said, I've
>> instrumented {SERVER,DIR}_{CREATE,MERGE}, which I think should cover
>> everything.
>
> PostConfig is called twice, because of the server startup:
> http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_Phases_Demonstration_Module
Right...I figured I could probably handle that by setting a flag
variable somewhere, or something of the sort.
Why are the PostConfig handlers being given config objects with
different addresses, though?
...hmm. It looks like they're being handed different server objects:
global_init server: Apache::Server=SCALAR(0x8caded0)
global_init server: Apache::Server=SCALAR(0x8c059e0)
Okay, this is starting to beg a question: why is PostConfig called
twice? What does each call represent? Why is it only called once for
an 'apachectl -k restart'?
And perhaps the question I should've asked to start with: if I need to
fork off one background process for the entire Apache server, what
handler should I do so in?
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Stas Bekman <st...@stason.org>.
Brent 'Dax' Royal-Gordon wrote:
> Stas Bekman wrote:
>
>> I still didn't have a chance to look at it in details, but could it be
>> the issue with merging not performing a deep copy?
>> http://perl.apache.org/docs/2.0/user/config/custom.html#Merging_Entries_Whose_Values_Are_References
>
>
>
> I don't think so--the only operation I do on that array is @{$arrayref}
> to flatten it out into a DBI argument list. (i.e. I never mutate it,
> which is where deep copying is important.)
>
>> If not, I'll look tomorrow on a fresh head, unless someone beats me to
>> it.
>
>
> I instrumented SERVER_CREATE, DIR_CREATE, SERVER_MERGE, DIR_MERGE,
> RegulateDatabase, and global_init to print the value of $self to the log:
>
> SERVER_CREATE: Apache::Regulate=HASH(0x831a330)
> SERVER_CREATE: Apache::Regulate=HASH(0x831a450)
> RegulateDatabase: Apache::Regulate=HASH(0x831a330)
> global_init: Apache::Regulate=HASH(0x831a450)
> global_init: Apache::Regulate=HASH(0x8105190)
>
> So what we're seeing is:
>
> a=SERVER_CREATE();
> b=SERVER_CREATE();
> RegulateDatabase(a, ...);
> global_init(b);
> global_init(c);
>
> I have no idea where 'c' is coming from--like I said, I've instrumented
> {SERVER,DIR}_{CREATE,MERGE}, which I think should cover everything.
PostConfig is called twice, because of the server startup:
http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_Phases_Demonstration_Module
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I have no idea where 'c' is coming from--like I said, I've instrumented
> {SERVER,DIR}_{CREATE,MERGE}, which I think should cover everything.
actually, probably too much :)
you haven't replied to my email yet, where it looks to me like some of your
directives are coming through just fine, but that got me thinking...
you sayid at the start that you have created one per-server directive and
several per-directory directives. you understand that the per-server and
per-dir object are different object, right? that ones created with
DIR_CREATE are not part of the SERVER_MERGE process so they will not show up
in the per-server object, even if they are used on a per-server level?
the rules to follow for custom directives wrt merging are this
- if you have only one directive, you do not need to write _any_ merge
routines
- if you define _both_ per-server _and_ per-directory directives then you
need to write _only_ DIR_CREATE and DIR_MERGE (though you can maintain them
separately from per-server directives if you wish).
- if you define _only_ per-server directives then you _should_ use
SERVER_CREATE and SERVER_MERGE (but the DIR_ equivalents will work as well,
they just add overhead).
the reasons for the later two rules are outlined at the end of recipe 7.10
http://www.modperlcookbook.org/chapters/ch07.pdf
unfortunately, the first rule didn't sink in until after the book came out,
so the example in 7.11 doesn't actually need the per-dir merging foo.
whether you are using mp1 or mp2, the stuff in chapter 7 is pretty valuable
if you're doing custom directive work. more equally valuable resources can
be found under the "More Information" header at the end of this article:
http://www.perl.com/pub/a/2003/07/08/mod_perl.html?page=3
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Brent 'Dax' Royal-Gordon <br...@brentdax.com>.
Stas Bekman wrote:
> I still didn't have a chance to look at it in details, but could it be
> the issue with merging not performing a deep copy?
> http://perl.apache.org/docs/2.0/user/config/custom.html#Merging_Entries_Whose_Values_Are_References
I don't think so--the only operation I do on that array is @{$arrayref}
to flatten it out into a DBI argument list. (i.e. I never mutate it,
which is where deep copying is important.)
> If not, I'll look tomorrow on a fresh head, unless someone beats me to it.
I instrumented SERVER_CREATE, DIR_CREATE, SERVER_MERGE, DIR_MERGE,
RegulateDatabase, and global_init to print the value of $self to the log:
SERVER_CREATE: Apache::Regulate=HASH(0x831a330)
SERVER_CREATE: Apache::Regulate=HASH(0x831a450)
RegulateDatabase: Apache::Regulate=HASH(0x831a330)
global_init: Apache::Regulate=HASH(0x831a450)
global_init: Apache::Regulate=HASH(0x8105190)
So what we're seeing is:
a=SERVER_CREATE();
b=SERVER_CREATE();
RegulateDatabase(a, ...);
global_init(b);
global_init(c);
I have no idea where 'c' is coming from--like I said, I've instrumented
{SERVER,DIR}_{CREATE,MERGE}, which I think should cover everything.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Stas Bekman <st...@stason.org>.
Brent 'Dax' Royal-Gordon wrote:
> Stas Bekman wrote:
>
>>> Even with a line in my httpd.conf like:
>>> PerlLoadModule Apache::Regulate
>>> RegulateDatabase 'dbi:mysql:apache' apache [redacted]
>>
>>
>> Please try:
>>
>> <Perl>
>> # start perl early
>> </Perl>
>> PerlLoadModule Apache::Regulate
>> RegulateDatabase 'dbi:mysql:apache' apache [redacted]
>
>
> Doesn't seem to have helped. Before and after adding those lines to
> httpd.conf, a Data::Dumper call in global_init gives:
>
> $VAR1 = bless( {
> 'on' => 0,
> 'Database' => [
> 'DBI:mysql:apache',
> 'apache',
> 'password'
> ],
> 'dead' => 0,
> 'ChunkSize' => '8000',
> 'TotalQuota' => '1966080',
> 'TotalBuffer' => 4
> }, 'Apache::Regulate' );
>
> Which is precisely the default configuration.
>
> For what it's worth, I ended up having to modify my output filter
> function to use this to load the full configuration:
>
> my %conf=(
> %{Apache::Module->get_config(__PACKAGE__, $f->r->server)},
> %{Apache::Module->get_config(__PACKAGE__, $f->r->server,
> $f->r->per_dir_config)}
> );
>
> Might a similar mixing be necessary in global_init?
I still didn't have a chance to look at it in details, but could it be the
issue with merging not performing a deep copy?
http://perl.apache.org/docs/2.0/user/config/custom.html#Merging_Entries_Whose_Values_Are_References
If not, I'll look tomorrow on a fresh head, unless someone beats me to it.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Brent 'Dax' Royal-Gordon <br...@brentdax.com>.
Stas Bekman wrote:
>> Even with a line in my httpd.conf like:
>> PerlLoadModule Apache::Regulate
>> RegulateDatabase 'dbi:mysql:apache' apache [redacted]
>
> Please try:
>
> <Perl>
> # start perl early
> </Perl>
> PerlLoadModule Apache::Regulate
> RegulateDatabase 'dbi:mysql:apache' apache [redacted]
Doesn't seem to have helped. Before and after adding those lines to
httpd.conf, a Data::Dumper call in global_init gives:
$VAR1 = bless( {
'on' => 0,
'Database' => [
'DBI:mysql:apache',
'apache',
'password'
],
'dead' => 0,
'ChunkSize' => '8000',
'TotalQuota' => '1966080',
'TotalBuffer' => 4
}, 'Apache::Regulate' );
Which is precisely the default configuration.
For what it's worth, I ended up having to modify my output filter
function to use this to load the full configuration:
my %conf=(
%{Apache::Module->get_config(__PACKAGE__, $f->r->server)},
%{Apache::Module->get_config(__PACKAGE__, $f->r->server,
$f->r->per_dir_config)}
);
Might a similar mixing be necessary in global_init?
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Stas Bekman <st...@stason.org>.
Brent 'Dax' Royal-Gordon wrote:
> Hello,
> I'm writing a pure-Perl Apache 2 module that installs a few custom
> directives. Four of the directives are only useful in the server root
> (i.e. outside of any VirtualHost, Directory, etc. directives), but three
> others make sense within containers.
>
> The directives seem to parse correctly, but when I try to access the
> configuration structure from a PostConfigHandler or ChildInitHandler,
> the resulting structure contains the default configuration, as if the
> directives had never been parsed at all. (I want a PostConfigHandler
> because I need to fork off a single background process for the entire
> server, and that seems like the easiest way to do so.)
>
> At the very least, I'm looking for a good example of a module that does
> something like this, but if someone can help me with the specific
> problem I'm having, that'd be even better.
[...]
> Even with a line in my httpd.conf like:
> PerlLoadModule Apache::Regulate
> RegulateDatabase 'dbi:mysql:apache' apache [redacted]
Please try:
<Perl>
# start perl early
</Perl>
PerlLoadModule Apache::Regulate
RegulateDatabase 'dbi:mysql:apache' apache [redacted]
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> sub SERVER_CREATE {
> return bless {
> Database => ['DBI:mysql:Regulate'],
> ...
> }, shift;
> }
> sub global_init #:PostConfigHandler
> {
> my(undef, undef, undef, $s)=@_;
> my $conf=Apache::Module->get_config(__PACKAGE__, $s);
> ...
> my $dbh=DBI->connect(@{$conf->{Database}}, {RaiseError=>1}) or
> global_init() dies with this error:
> DBI connect('Regulate','HASH(0x8a377ec)',...) failed: Access denied
> for user: '@localhost' to database 'Regulate'
>
> Which leads me to believe that either the information isn't being
> recorded for some reason, or I'm looking at the wrong $conf structure.
it looks to me like it's picking up the 'Regulate' database from
SERVER_CREATE just fine. I don't suppose that you have just dumped the
values you think you set from $conf, forgetting about DBI for the moment,
just to see what has and has not made it through?
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html