Why not just inject the filter where you like by index into the filter
list - no need to move around interceptor order. If there is no add
with index position let's expose it. WDYT?
Sent from my iPhone
On Jan 6, 2011, at 6:10 PM, Emmanuel Lecharny <[email protected]>
wrote:
Hi,
while working on the AP handling, I faced some issue today with the
search operation. The problem is that when we get back an entry from
the backend, we filter it to add or remove some attributes, and to
accept or not the entry. Usually, the following filters are executed :
1) collective filter
2) HideSubentriesFilter
3) SeqNumberUpdateFilter
4) TopFilter
5) DefaultAuthorizationFiler
(in the given order).
As we can see, the colelctive filter is executed first. It adds the
collective attributes if there is a subentry selecting the entry.
The problem is that at this point, we don't yet know if the entry is
associated with a subentry, as we expect the next filter
(SeqNumberUpdateFilter) to add the attribute containing the
reference to the subentry.
Bottom line, we don't have the collective attributes added to the
entry in this case.
There is one simple solution : inverting those two intecreptors in
order to have the subtreeInterceptor being executed before the
CollectiveAttributeInterceptor.
I don't think this could have any impact on the server, I will test
that in trunk.
I'll update you asap.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
