directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ADS 2.0] OSGi, interceptors
Date Thu, 13 Oct 2011 12:23:18 GMT
On Thu, Oct 13, 2011 at 3:05 PM, Emmanuel Lécharny <>wrote:

> On 10/13/11 1:44 PM, Alex Karasulu wrote:
>> On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny<>*
>> *wrote:
>>  Hi,
>>> Göktük asked if there is a way to transform Interceptors to be bundles
>>> instead of being statically loaded in core.
>>> I tried to play around the idea yesterday in the train, and I faced some
>>> interesting challenges.
>>> o First, many interecptors are doing calls to the chain again, but with a
>>> restricted set of interceptors. For instance, in the SchemaInterceptor,
>>> we
>>> go through the chain again when modifying the schema itself. In order to
>>> speedup the operation, we declare a BYPASS sets of interceptors (I'm not
>>> sure it's a good idea, but right now, this is how we proceed). At the
>>> end,
>>> this BYPASS set is declared this way :
>>>    private static final Collection<String>  BYPASS;
>>>    static
>>>    {
>>>        Set<String>  c = new HashSet<String>();
>>>        c.add( AuthenticationInterceptor.****class.getName() );
>>>        c.add( AciAuthorizationInterceptor.****class.getName() );
>>>        c.add( DefaultAuthorizationIntercepto****r.class.getName() );
>>>        c.add( ExceptionInterceptor.class.****getName() );
>>>        c.add( SchemaInterceptor.class.****getName() );
>>>        BYPASS = Collections.****unmodifiableCollection( c );
>>>    }
>>> As we can see, it creates a static dependency on interceptors. It might
>>> be
>>> a better idea to use logical names instead of class names, and let the
>>> OSGi
>>> container retrieve the classes itself.
>>>  This is a good idea. How about going a little further and having a set
>> of
>> interceptor chain re-entry constants or set of enum values like:
>> etc ...
>> This is like saying we do not need authentication, authorization,
>> additional
>> exception handling and checks or schema checking on re-entry instead of
>> having a direct list of interceptors to avoid.
> That's a good idea.
> One thing that might be problematic though is that we have no idea which
> interceptors are going to be present in the chain, so we may be unable to
> tell the chain not to use the interceptors added on the fly (for instance,
> the logger interceptor).
Good point. Perhaps this is where we can have some kind of generic property
that states whether or not by default on re-entry the interceptor should be
included or excluded. There's a system default, say exclude by default
always. Then the interceptor might override this with some class property
like excludeOnReentry?

This way even though the IC does not know which interceptors are present it
can react accordingly on reentry. So for this logger interceptor example it
might have excludeOnReentry set to false in which case it will always be
included when present which makes send. We would not add the interceptor if
we did not want to log reentrant invocations.

> I'd rather create a set of interceptors we want to go through, as we know
> which one we will use in those internal cases.
> In any case, using constants instead of class name is the way to go.
Yes this is definitely the first step, perhaps the final step but perhaps
you might want to entertain the idea of evaluating inclusion or exclusion
based on properties. This makes debugging a tiny bit more complicated but it
gives us a more pluggable way to manage the IC.

>> Then Interceptors when they register themselves can announce what standard
>> functions they perform according to this set. Some may not announce at all
>> if they perform none of these functions. This way the chain determines
>> what
>> to include and what to exclude based on these properties. There's no
>> direct
>> link with the interceptor itself and any implementation can be swapped in
>> and out.
>> This way we are letting the interceptor chain devise the proper chain of
>> interceptors based on these properties instead of using more explicit
>> names
>> or direct references to the interceptor classes.
> Ultimately, for each operation (add, delete, lookup, etc), we should be
> able to define the set of interceptors we are going through.

My thinking is to not define things in terms of interceptors to go through
or not go through for each operation but rather we should define the aspects
to include or exclude on re-entry into the IC for each operation. Keeping it
generic this way, and having the Interceptor tell the IC which aspects it
participates in allows the IC to include or exclude on re-entry.

> This should be defined somewhere in the code, not in each interceptors. It
> may even be some configurable information...
I see two points of configuration.

One configuration is the IC configuration it self which includes the aspects
to include or exclude on re-entry for each of the add, delete, lookup etc
operations. The IC itself is a component with this perspective.

The Interceptors themselves each have a configuration. In this configuration
the Interceptor should expose what aspects it participates in. For example
FooInterceptor might expose that it participates in the authentication
aspect. This way the IC knows for example in a schema modification operation
that causes re-entry to occur, this aspect is excluded say during a modify
operation since the session is already authenticated (no need to perform
this twice or on each re-entry into the IC). The FooInterceptor will be
bypassed in this case.

>> There can also be other hint mechanisms given to the interceptor chain so
>> it
>> can correctly asses which interceptors to include or exclude on re-entry.
>> For example there could be properties exposed for defaults on the
>> interceptor telling the chain always exclude on re-entry etc. There should
>> be some more thought put on this but the present situation as you state
>> sucks where OSGi and pluggability is concerned.
> Right. We will try to get OSGi implemented anyway, and once it's done, we
> can start thinking about a better mechanism.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

Best Regards,
-- Alex

View raw message