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 17:56:21 GMT

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

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.

> Not sure, but I think what I've described above would work for  
> embedded implementations too...
> --
> Matt
> P.S. - I'm still looking for an elegant way to implement  
> interceptor bypass in the current 1.x codebase.  Still haven't  
> found one that wouldn't also change the Interceptor interface  
> (resulting in a cascade of changes).  Looking at a few more ideas  
> before I give up.

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.

david jencks

> On 10/4/07, Alex Karasulu <> wrote:
> Also at some point we may include two sets of operation  
> parameters.  One set is the
> original set of parameters for the operation without any  
> alterations taking place such as
> those with normalization or other optimizations.  Another set will  
> be the same parameters
> tweaked by the system which should be applied by partitions.
> These are considerations for our bigbang branch which is  
> refactoring the 1.5 line for a
> 2.0 release.  I think by providing the original request objects in  
> the operation context as
> well as the modified versions of them your problem will probably go  
> away.
> Still though feel welcome to follow this activity to make sure your  
> needs are met as
> we change the server's architecture.  Any recommendation or  
> involvement would be
> highly appreciated.
> Alex
> On 10/4/07, Matt Peterson < > wrote:
> Ok.  I will.  Thanks.
> On 10/3/07, Alex Karasulu < > wrote:
> Yes I understand. If you would like to implement this bypass  
> capability based on the target DN then feel
> free to submit a patch.
> Thanks,
> Alex
> On 10/3/07, Matt Peterson < > wrote:
> Greetings,
> I'm trying to write a custom partition that will be used as context  
> partition, but I'd like to continue to use the Btree/Jdbm partition  
> implementation for the system configuration partition.
> With a little trial and error (mostly errors), I've found out that  
> several methods in the JdbmPartition (used by the system  
> configuration partition partition) will not work unless preceeded  
> by a corresponding "fix-ups" provided by the interceptors.  For  
> example, calls to to the methods in  
> must be made, or BindDNs can not be resolved.  Unfortunately,   
> MyCustomPartition, doesn't like the way that LdapDNs, attributes  
> and filters are normalized by  
> In other words, there appears to be more than at least one  
> situation where a correlation between interceptors and partitions  
> is necessary, but what we have (at least in Apache DS 1.0.x) is a  
> design where all interceptors in the chain are called regardles of  
> the partition that will eventually be invoked. To configure per- 
> partition interception.
> Perhaps what I'm looking for is a way that I can insert my  
> interceptor first in the chain and then optionally skip other  
> interceptors if I encounter a DN or base that I know will invoke my  
> partition?  According to documentation for ApacheDS 1.0.x (http:// 
> the Nexus is  
> called by a "special interceptor" at the end of the chain.   
> Therefore, it seems very difficult to skip interceptors in the  
> chain without also elimintating the call to PartitionNexus ...
> I suppose my real question is why ApacheDS wasn't designed so that  
> interceptors could (optionally) be configured for association only  
> with a certain suffix or partition.  This would allow the  
> configuration flexibility that I would need -- to use both the  
> JdbmPartition and my own customPartition without having to undo all  
> of the normalization, schema, referral (,etc) stuff in my own  
> customPartition that I didn't want done in the first place...
> Does this make any sense?
> --
> Matt

View raw message