directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: [ADS 2.0] OSGi, interceptors
Date Thu, 13 Oct 2011 14:39:51 GMT
On 10/13/11 4:30 PM, Alex Karasulu wrote:
>>>   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,
>>>>>>> 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
>>>>>>> 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.
>>>>>>> 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
>>>>>>> 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
>>>>>> 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.
>> IMO, the best would be to declare sets of (I) we should go through, instead
>> of sets of (I) we should bypass. This way, we will be able to know what is
>> being executed, and we won't provide a way for users to pollute the internal
>> executions of operations (keep in mind that those internal operation are
>> themselves called by other operations).
>> We can also declare those sets in the configuration, for each operation, so
>> if we want to allow someone to modify the execution order, it's still
>> possible to do so. (it can be done later though).
> Perhaps we should break this out and discuss this in a separate thread. The
> reason historically for listing what you should not execute was a poor
> attempt to decouple and well you just don't know what extra interceptors you
> have.
> I have some ideas here that I also want to think through as well then post.

Sure, create another thread.

Emmanuel L├ęcharny

View raw message