directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Relationship of Interceptors and Partitions
Date Fri, 05 Oct 2007 03:47:56 GMT
On 10/4/07, David Jencks <> wrote:

> On Oct 4, 2007, at 11:21 AM, Alex Karasulu wrote:

SNIP ...

If this idea of configuring lots of interceptor lists in server.xml worked
> > out it might be pretty easy for these to be specified per partition as well.
> >
> I think we could have a combinatorial explosion if we did this.  Perhaps
> partitions should just
> expose their "skiplist" rather than defining a chain specifically for each
> partition's suffix for each
> operation.
> The combinatorial explosion certainly seems like a real danger.   I kind
> of think the skip list goes with the operation better than with the
> partition.

The skip list can also go into the interceptor.  Interceptors may be
configured with a set of distinguished names
to be skipped.  The InterceptorChain can leverage this information to
automatically bypass an interceptor based
on the distinguished name of the target entry the operation is performed on.

If the functional names you talk about below (i.e. "normalization" ) can be
configured in the interceptor for different
regions of the DIT then this can be controlled pretty well.  This
alternative my be better at targeting specific functionality.
For example Matt will want to just skip one or two interceptors at most for
his partition.  Configuring this as an exception
on the interceptor may be best.  Don't know tho.

BTW there are major concerns with bypassing interceptors where bypassing one
interceptor may cause another to
fail. This nasty coupling is what I want to get rid of but don't know how

Thinking about how the skip lists work now I recall that they aren't based
> on interceptor identity but name although in trunk the name is by default
> the class name of the interceptor.  lets see if I can explain this so anyone
> can understand what I'm thinking.... if the skip lists work by functional
> name and the partitions supply the skip lists with the interceptors named
> functionally then the skip lists would work with different interceptor
> chains even though the implementation of some functions would be with
> different classes.
> e.g. the normalization would be done by a different interceptor in the
> normal and the Matt partitions, but they'd have the same name... so if a
> skip list included "Normalization" that interceptor, whatever it happened to
> be for the target partition, would get skipped.

Yes we should use symbolic/functional names you suggest instead of the
interceptor class name.

I'll try to explain again from a different point of view...
> - partitions specify a "complete" interceptor stack for themselves.  The
> interceptors have functional names that reflect what they do rather than
> necessarily their class.

The "complete" part sounds like it might lead to greater verbosity and might
also cause other severe problems
where we cannot have two instances of the same interceptor in the same
DirectoryService.  Perhaps we can use
reuse but still there will be one offs and issues if we do do that.

- skip lists are based on these functional names


- there's something before we get into the interceptor stack that picks the
> right interceptor stack based on the target partition

This can be done but there are just some functions (interceptors) that must
be handled or else critical services fail.

- the skip lists now work for any interceptor stack because they say what
> functionality to skip.
> What I don't know is if (3), the thing that picks the correct interceptor
> stack, is possible to write.

Yeah I worry sometimes.  You've got some great ideas and I'm learning a lot
from you.  I'm very appreciative
regarding that.  However you have not been bit by this mechanism as much as
we have.  It's made us suffer
a lot :).  It really takes getting shocked a few times to have the pavlovian
response which people like myself and
Emmanuel have when dealing with these interceptors and the chain mechanism.
All the pain comes rushing back into
our heads when we consider our options.  I'm learning a lot from your keen
insight and design ideas but I hope you
have some of our challenges cached in mind when considering some of these
options.  It will just make us more
efficient while discussing these things.  I know we cannot instantly give
you the background knowledge but you're
still very insightful all the same. Perhaps in time you'll begin to see the
nasty issues we have but that kind of takes
looking at how we implement protocol specific features a bit: I don't know
if this something you want to delve into
since it's a bottomless pit.  To a degree tho you can piggy back on our
experiences.  Anyways ...

Perhaps we can discuss other patterns in addition to seeing what could be
done to make the present more one
capable of satisfying our needs.  I think we're onto some good ideas tho.
We just need to think about the pros and


View raw message