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 Thu, 04 Oct 2007 18:21:50 GMT
On 10/4/07, David Jencks <> wrote:
> On Oct 4, 2007, at 10:38 AM, Matt Peterson wrote:
> Alex,
> I'm not sure that including two sets of operational parameters for calls
> to the partition is the right answer.  Doing this would allow partitions to
> be written that could not benefit from optimizations made by interceptors.
> I like the interceptor paradigm because it encourages modularity and code
> reuse. I think that it would be wise to "encourage" partition authors to use
> interceptors appropriately and not embed into the partition what should be
> in an interceptor.
> However, it would also be wise to allow users the option of not using
> certain interceptors with a particular partition. In other words, we need
> per-partition interceptor configuration.  I'm fairly focused on my current
> project, but I think it would be generally useful to make the interceptor
> configurations a property of the partition configuration (in server.xml).
> This way users can select the set of interceptors that they'd like to use
> with a given partition.  Situations where interceptor functionality is
> required by a partition (such as normalization) could easily be detected in
> individual partition initialization code and result in the appropriate
> (graceful) warning or failure.
> I think its clear that there are problems with the current "skip list"
> approach when people add custom interceptors that perhaps should only be
> used in some circumstances.

The problem resides in the fact that you cannot list the interceptors to use
since you don't know if they will be present.  So the only option is the
skip list but yes this data structure is not serving us well.  Plus on top
of this there are all sorts of interceptor dependencies which is causing
serious coupling issues.

I've wondered if this problem could be solved by explicitly configuring the
> interceptor lists for each purpose in the spring xml rather than any of
> hardcoding the skips (current approach), hardcoding the "applies" (opposite
> and perhaps even worse approach) or building a logic engine to decide (I
> think this has in fact been tried by some projects).  I think jetspeed uses
> an approach similar to "configure lots of lists explicitly".

You know this sounds similar to an idea I have been bouncing around with
Emmanuel.  Using a variant of the CoR pattern to have a different chain for
each operation: i.e. add, modify, ...

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

> Not sure, but I think what I've described above would work for embedded
> implementations too...
> Personally I think it's slightly easier to understand what is going on in
> the bigbang branch and if you pursue something like the "explicit lists"
> approach we could actually commit it without rewriting if you work against
> that moving target.

Perhaps we need more discussion around different patterns that we can use to
solve these problems.  It's not something we'll be getting to soon in the
code until all the JNDI demolition settles so this gives us some time to
research and discuss.


View raw message