directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Relationship of Interceptors and Partitions
Date Thu, 04 Oct 2007 19:23:37 GMT

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

> 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
> 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.

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.

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.
- 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
- 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.

>> 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.

david jencks

> Alex

View raw message