Johnny Shz <[EMAIL PROTECTED]> wrote:
> I couldn't seem to find an equivalent in mod_perl 2, Apache2::Request
> allows retrieving parameters by its param() method, but no way to set
> the parameters to be processed further down the chain.
Apache2::Request removed the ability to set the request pa
Fred Moyer <[EMAIL PROTECTED]> wrote:
> But... once I changed my return codes to allow the other handlers to
> return DECLINED instead of OK in a couple of particular situations,
> push_handlers() behaved as I would have expected it to. I'm guessing
> that your PerlFixupHandler is set to return
I'm having some frustration with managing Perl handler registrations.
It seems that, if I register a handler from within my code, either using
push_handlers or by grabbing the list with get_handlers, modifying it,
and then doing set_handlers -- any other handlers for that phase that
were registere
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> You keep the handle in a global and then clear it from a cleanup
> handler?
I actually keep it in an object instance, but same thing, since I'm
caching the object in a global that gets removed from a cleanup handler.
The object wraps all the functional
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> If you have some code that is caching $dbh in a global or closure, and
> not calling Apache::DBI->connect() on every request, it can't replace
> that, and neither can DBI->connect_cached(). That defeats the auto-
> reconnect features of both. I recom
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> my $cache = $dbh->FETCH('CachedKids');
>
> That should return cached handles from the current $dbh, not an old one
> that has been replaced. The statement handles are attached to the
> database handle, so if it gets replaced, all the old ones go away.
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> The prepare_cached() method he's using will check the statement handle
> and prepare it again on the new connection if necessary.
Not with Apache::DBI, though. The reconnect happens underneath DBI, and
you end up with the same $dbh, which thinks the
Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> [Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
> prepare_cached failed: FATAL: terminating connection due to administrator
Here's the thing: if your database connection goes away, and Apache::DBI
opens a new one, any prepared s
Josh Narins <[EMAIL PROTECTED]> wrote:
>> Is it breaking anything?
>
> A fixup handler that says "if the url matches /baz/" then do a little work
> here. That work ends up getting done twice (including, in just one instance,
> saving something to the DB, where I get double entries). For instanc
Josh Narins <[EMAIL PROTECTED]> wrote:
> I also tried /foo/bar/blah and tried this once (i.e. it tried /foo/bar, and
> didn't end up trying simply /foo)
Hmm, wait... you'd said that a request for /foo/bar resulted in the
subrequest for /bar... is it that, or is it looking up /foo -- ie, the
equi
Josh Narins <[EMAIL PROTECTED]> wrote:
> As you suspected, everything in the second set returns 0 for
> $r->is_initial_req().
>
> However, I never call internal_redirect.
>
> What else might be doing it?
>
> To make sure you are confused, the first request returns the content, and I
> have no
Josh Narins <[EMAIL PROTECTED]> wrote:
> PostReadRequest /foo/bar
> Trans /foo/bar
> HeaderParser /foo/bar
> Access /foo/bar
> Fixup /foo/bar
> Trans /bar
> HeaderParser /bar
> Access /bar
> Fixup /bar
> PerlHandler
>
> What is causing my server to restart at the Trans phase with the truncated
>
Leo Lapworth <[EMAIL PROTECTED]> wrote:
> I don't think this would work...
>
> You can set up a global variable within your startup.pl (before apache
> spawns child processed) and all children will get it, but if you
> edit it in anyway the changes are only reflected in that specific child
> pro
John Doe <[EMAIL PROTECTED]> wrote:
> Hope it's not a stupid question, but are you sure %d_cache survives a
> request? Maybe I'm totally misunderstanding something but I thought
> after the point
>
> } end lexical scope
>
> %d_cache gets destroyed (if not still referenced from somewhere else)
Peter1 Alvin <[EMAIL PROTECTED]> wrote:
> Please tell me I can do this!
>
> Using mod_perl, how do you keep Perl objects in RAM from page to page?
> I don't want to re-instantiate my objects on every page request, and I
> don't want the overhead of serializing my objects to a persistent store
Geoffrey Young <[EMAIL PROTECTED]> wrote:
> your description sounds correct for default behavior. and I think it
> matches what you quoted :)
Hmm. I took the description in the docs to mean that the directives would
override the "above" config on a per-directive basis. It certainly didn't
occ
I've recently moved to Apache2, and I'm now at my wit's end with custom
configuration directives. I have them defined and working, following the
examples in the docs, but the merging behavior is proving difficult to
understand.
(Using mod_perl 2.0.2, apache 2.0.55, perl 5.8.7, FreeBSD 6.0RC1.)
A
17 matches
Mail list logo
