Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.220.216 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=BIYQ/lfPtOdQIwEzX1nK4SXuyeXlXh33D5xbPvs9b55tqbYss1oevUnSKkJGQcE/pm
         4TIyoGVWiwsb+dLhnMNFOKB+k3fh7DJT5p71nTcm5qeqxGAKpYi66t0NF8Aze6mmnJ2U
         +dkDvWt7YkiTUkd0L8xUKTjmt/mx2atsopJpY=
MIME-Version: 1.0
Date: Fri, 15 May 2009 15:26:49 -0400
Message-ID: <cc67648e0905151226g4fbfec0fhc6b5a998cccbc57e@mail.gmail.com>
Subject: [PATCH] handling hook predecessors when predecessor has hooked more
	than once
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Content-Type: multipart/mixed; boundary=000e0cd29778122e550469f86d7e

--000e0cd29778122e550469f86d7e
Content-Type: multipart/alternative; boundary=000e0cd29778122e480469f86d7c

--000e0cd29778122e480469f86d7c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

mod_p hooks the post_config more than once, including really_last.  mod_s's
post_config has to run after mod_p's post_config (both of them) for one of
its features to work.  I tried adding "mod_p.c" to the predecessor list in
mod_s, but it wasn't effective, as predecessor processing doesn't account
for the possibility that the predecessor may have hooked more than once.

No claims here to understand all the hook sorting; I found some code that I
was expecting, changed it, was happy, changed the LoadModule order, was
still happy, but noted that there's some other, less obvious code that
touches predecessors too (tsort()).

Any thoughts before I test in more detail?

--000e0cd29778122e480469f86d7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

mod_p hooks the post_config more than once, including really_last.=A0 mod_s=
&#39;s post_config has to run after mod_p&#39;s post_config (both of them) =
for one of its features to work.=A0 I tried adding &quot;mod_p.c&quot; to t=
he predecessor list in mod_s, but it wasn&#39;t effective, as predecessor p=
rocessing doesn&#39;t account for the possibility that the predecessor may =
have hooked more than once.<br>
<br>No claims here to understand all the hook sorting; I found some code th=
at I was expecting, changed it, was happy, changed the LoadModule order, wa=
s still happy, but noted that there&#39;s some other, less obvious code tha=
t touches predecessors too (tsort()).<br>
<br>Any thoughts before I test in more detail?<br><br><br>

--000e0cd29778122e480469f86d7c--

--000e0cd29778122e550469f86d7e
Content-Type: text/plain; charset=US-ASCII; name="hook_order.txt"
Content-Disposition: attachment; filename="hook_order.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fur9wx0f0

SW5kZXg6IGhvb2tzL2Fwcl9ob29rcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGhvb2tzL2Fwcl9ob29rcy5j
CShyZXZpc2lvbiA3NzM1MjIpCisrKyBob29rcy9hcHJfaG9va3MuYwkod29ya2luZyBjb3B5KQpA
QCAtOTYsOCArOTYsOSBAQAogICAgIGZvcihuPTAgOyBuIDwgbkl0ZW1zIDsgKytuKSB7CiAJaW50
IGksazsKIAorICAgICAgICAvKiBzdG9wIGF0IGxhc3QgaW5zdGFuY2Ugb2YgYSBwcmVkZWNlc3Nv
ciBpZiBwcmVzZW50IG11bHRpcGxlIHRpbWVzICovCiAJZm9yKGk9MCA7IHBJdGVtc1tuXS5hc3pQ
cmVkZWNlc3NvcnMgJiYgcEl0ZW1zW25dLmFzelByZWRlY2Vzc29yc1tpXSA7ICsraSkKLQkgICAg
Zm9yKGs9MCA7IGsgPCBuSXRlbXMgOyArK2spCisJICAgIGZvcihrPW5JdGVtcy0xIDsgayA+PSAw
IDsgLS1rKQogCQlpZighc3RyY21wKHBJdGVtc1trXS5zek5hbWUscEl0ZW1zW25dLmFzelByZWRl
Y2Vzc29yc1tpXSkpIHsKIAkJICAgIGludCBsOwogCkBAIC0xMDksNiArMTEwLDcgQEAKIAkJZ290
X2l0OgogCQkgICAgYnJlYWs7CiAJCX0KKyAgICAgICAgLyogc3RvcCBhdCBmaXJzdCBpbnN0YW5j
ZSBvZiBhIHN1Y2Nlc3NvciBpZiBwcmVzZW50IG11bHRpcGxlIHRpbWVzICovCiAJZm9yKGk9MCA7
IHBJdGVtc1tuXS5hc3pTdWNjZXNzb3JzICYmIHBJdGVtc1tuXS5hc3pTdWNjZXNzb3JzW2ldIDsg
KytpKQogCSAgICBmb3Ioaz0wIDsgayA8IG5JdGVtcyA7ICsraykKIAkJaWYoIXN0cmNtcChwSXRl
bXNba10uc3pOYW1lLHBJdGVtc1tuXS5hc3pTdWNjZXNzb3JzW2ldKSkgewo=
--000e0cd29778122e550469f86d7e--