What's the purpose and what are the use cases for the methods
get_handler and set_handler available from Apache2::RequestUtil
and Apache2::ServerUtil?
I don't have a concrete use case myself where I'd think these methods
might fit; I'm just studying the API and trying to make sense of it.
--
Michael Ludwig
On Mon, Mar 22, 2010 at 7:50 PM, Michael Ludwig
> What's the purpose and what are the use cases for the methods
> get_handler and set_handler available from Apache2::RequestUtil
> and Apache2::ServerUtil?
These are explained with examples in the docs:
http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html
Is there something there that's confusing you? Can you ask a more
specific question?
- Perrin
Perrin Harkins schrieb am 23.03.2010 um 13:08:27 (-0400):
>
> These are explained with examples in the docs:
> http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html
>
> Is there something there that's confusing you? Can you ask a more
> specific question?
I did see the examples in the doc but fail to understand their
relevance. The first one goes:
# A list of handlers configured to run at the response phase:
my @handlers = @{ $r->get_handlers('PerlResponseHandler') || [] };
Now what do I do with that bunch of code references? I think there might
be something useful about this that escapes me.
Almost the same story for set_handlers: Do people use this to
dynamically reconfigure their server? Could it be used to dynamically
take a handler out of service once a certain error condition is met
with, like, say, a Berkeley database in need of recovery (which requires
single-threaded access to perform), or a search engine backend having
become irresponsive?
What have you used these functions for in real code?
I'm sorry I don't have a concrete use case of my own at hand - I'm
really only try to figure out the details of the API so I know how to
best make use of it.
--
Michael Ludwig
On Tue, Mar 23, 2010 at 2:54 PM, Michael Ludwig
> =A0# A list of handlers configured to run at the response phase:
> =A0my @handlers =3D @{ $r->get_handlers('PerlResponseHandler') || [] };
>
> Now what do I do with that bunch of code references? I think there might
> be something useful about this that escapes me.
If you want to know what handlers are set to run for the current
request, this is how you find out.
> Almost the same story for set_handlers: Do people use this to
> dynamically reconfigure their server? Could it be used to dynamically
> take a handler out of service once a certain error condition is met
> with, like, say, a Berkeley database in need of recovery (which requires
> single-threaded access to perform), or a search engine backend having
> become irresponsive?
More likely you would use them to do your own dispatch of some kind
where you choose between multiple possible handlers based on something
about the request.
> What have you used these functions for in real code?
Sometimes people use them to tell apache to handle a certain request
as a static file and skip the mod_perl response handler that would
normally be configured for the URI.
- Perrin
Perrin Harkins schrieb am 23.03.2010 um 15:14:56 (-0400):
> On Tue, Mar 23, 2010 at 2:54 PM, Michael Ludwig
> > # A list of handlers configured to run at the response phase:
> > my @handlers = @{ $r->get_handlers('PerlResponseHandler') || [] };
> >
> > Now what do I do with that bunch of code references? I think there
> > might be something useful about this that escapes me.
>
> If you want to know what handlers are set to run for the current
> request, this is how you find out.
Well, you don't - unless you can tell from the code reference which
handler it actually is. With code reference, ususally you have to know
(or do not care) what reference it is. It is only when you call it that
you find out.
> > Almost the same story for set_handlers: Do people use this to
> > dynamically reconfigure their server? Could it be used to
> > dynamically take a handler out of service once a certain error
> > condition is met with, like, say, a Berkeley database in need of
> > recovery (which requires single-threaded access to perform), or a
> > search engine backend having become irresponsive?
>
> More likely you would use them to do your own dispatch of some kind
> where you choose between multiple possible handlers based on something
> about the request.
Okay, I can see that for the case of setting a handler on the current
request. But I figure it can get pretty confusing if you reconfigure
your server by calling set_handlers on the Apache2::ServerRec object as
shown here:
http://perl.apache.org/docs/2.0/api/Apache2/ServerUtil.html
How do people keep track of who configured what handlers, and what is
the current handler? I would have to receive a name in addition to the
code ref from get_handlers in order to determine the current state of
affairs. So how is this used in practice? Or isn't it?
> > What have you used these functions for in real code?
>
> Sometimes people use them to tell apache to handle a certain request
> as a static file and skip the mod_perl response handler that would
> normally be configured for the URI.
That makes sense, but I would rather have taken care to ensure that only
properly dynamic requests hit mod_perl. Thanks nonetheless. But I'm
still eager to learn more :-)
--
Michael Ludwig
Michael Ludwig schrieb am 23.03.2010 um 00:50:43 (+0100):
> What's the purpose and what are the use cases for the methods
> get_handler and set_handler available from Apache2::RequestUtil
> and Apache2::ServerUtil?
My desire to believe in the wisdom of the designers of the API has kept
me busy thinking about this. Considering that we have:
* get_handlers
* set_handlers
* push_handlers
It occurred to me that push_handlers could be implemented in terms
of get_handlers and set_handlers; and so could a merely hypothetical
unshift_handlers, which isn't there, and that could be the raison
d'être of get_handlers.
Maybe dynamic reconfiguration on a per-request basis as in this example
for a MyApache2::SendEmail handler [1] is what this is about.
Plus the same kind of thing for the whole server. Maybe you would
like to retire a certain handler at a given point in time, or on some
condition being met; you would then call set_handlers to install a new
handler and not have to do additional maintenance.
Any thoughts or comments you might have are welcome.
--
Michael Ludwig
On Tue, Mar 23, 2010 at 3:47 PM, Michael Ludwig
> Well, you don't - unless you can tell from the code reference which
> handler it actually is.
You could examine a coderef if you really needed to. You could also
get the list of handlers, add something to it, and set it again. If
you notice, set clears the previous handlers.
I don't know if anyone uses this.
> Okay, I can see that for the case of setting a handler on the current
> request. But I figure it can get pretty confusing if you reconfigure
> your server by calling set_handlers on the Apache2::ServerRec object as
> shown here:
Well, if you find it confusing, I'd advise you not to do it. I wouldn't do it.
> How do people keep track of who configured what handlers, and what is
> the current handler?
Dynamic configuration of handlers is a pretty specialized situation
that you'd only use if you needed it. Normally you'd just configure
them in your conf file.
>> Sometimes people use them to tell apache to handle a certain request
>> as a static file and skip the mod_perl response handler that would
>> normally be configured for the URI.
>
> That makes sense, but I would rather have taken care to ensure that only
> properly dynamic requests hit mod_perl.
Yes, obviously you would only do this for something where the decision
about what handler to run is actually dynamic based on the request or
some other current information. People often ask about it though.
You can see some typical questions in the mail archives if you search
for "default-handler."
- Perrin
Michael Ludwig schrieb am 23.03.2010 um 21:51:48 (+0100):
> Maybe dynamic reconfiguration on a per-request basis as in this
> example for a MyApache2::SendEmail handler [1] is what this is about.
[1] http://perl.apache.org/docs/2.0/user/handlers/http.html
--
Michael Ludwig
Perrin Harkins schrieb am 23.03.2010 um 16:54:44 (-0400):
> On Tue, Mar 23, 2010 at 3:47 PM, Michael Ludwig
> You could examine a coderef if you really needed to.
Using some forsaken B:: module? Such wizardly demanour does raise some
eye-brows with your fellow workers.
> > Okay, I can see that for the case of setting a handler on the
> > current request. But I figure it can get pretty confusing if you
> > reconfigure your server by calling set_handlers on the
> > Apache2::ServerRec object as shown here:
>
> Well, if you find it confusing, I'd advise you not to do it. I
> wouldn't do it.
Thanks. That makes me feel less uncertain about this dynamic handler
configuration business.
> > How do people keep track of who configured what handlers, and what
> > is the current handler?
>
> Dynamic configuration of handlers is a pretty specialized situation
> that you'd only use if you needed it. Normally you'd just configure
> them in your conf file.
Right. Never done anything else to this day.
> Yes, obviously you would only do this for something where the decision
> about what handler to run is actually dynamic based on the request or
> some other current information. People often ask about it though. You
> can see some typical questions in the mail archives if you search for
> "default-handler."
Thanks. Found some good examples. Although it seems to me that for such
a case you would rather call $r->handler( 'default-handler' ), which is
a pendant to 'perl-script', 'cgi-script' and others. But unless I'm
mistaken here, this is not the same as the handlers we can manipulate
using get_handlers, set_handlers and push_handlers, since these are
sub-handlers of 'perl-script' (or any other Apache handler, for that
matter).
See this short thread to get the context of what I'm referring to:
Defaulting to default-handler from custom handler
http://www.gossamer-threads.com/lists/modperl/modperl/51739
--
Michael Ludwig
On Tue, Mar 23, 2010 at 4:51 PM, Michael Ludwig
> My desire to believe in the wisdom of the designers of the API has kept
> me busy thinking about this.
Keep in mind that most of the Perl API is just exposing the apache
module API to Perl. It wasn't necessarily put there with a (Perl) use
in mind.
- Perrin
On Tue, Mar 23, 2010 at 6:03 PM, Michael Ludwig
> Thanks. Found some good examples. Although it seems to me that for such
> a case you would rather call $r->handler( 'default-handler' ), which is
> a pendant to 'perl-script', 'cgi-script' and others. But unless I'm
> mistaken here, this is not the same as the handlers we can manipulate
> using get_handlers, set_handlers and push_handlers, since these are
> sub-handlers of 'perl-script' (or any other Apache handler, for that
> matter).
It's not exactly the same, but if you were to use it would probably be
for a similar purpose.
- Perrin
Am 24.03.2010 um 13:08 schrieb Perrin Harkins:
> On Tue, Mar 23, 2010 at 4:51 PM, Michael Ludwig
>> My desire to believe in the wisdom of the designers of the API has kept
>> me busy thinking about this.
>=20
> Keep in mind that most of the Perl API is just exposing the apache
> module API to Perl. It wasn't necessarily put there with a (Perl) use
> in mind.
Good point. While all this low-level work is certainly feasable in Perl, gi=
ven the weight of a typical mod_perl application it is not necessarily desi=
rable to burden it with such work.
--=20
Michael.Ludwig (#) XING.com