directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [ADS 2.0] OSGi, interceptors
Date Thu, 13 Oct 2011 11:44:01 GMT
On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny <elecharny@apache.org>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:

ReEntry.NO_AUTHENTICATION
ReEntry.NO_AUTHORIZATION
ReEntry.NO_ERROR_CHECKING
ReEntry.NO_SCHEMA_CHECKING

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.

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.

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.


> o Second, we have places in core were we call the interceptors, like in
> DefaultDirectoryService :
>
>    public boolean isPwdPolicyEnabled()
>    {
>        AuthenticationInterceptor authenticationInterceptor =
> (AuthenticationInterceptor)**getInterceptor( AuthenticationInterceptor.**class.getName()
> );
>        if ( authenticationInterceptor == null )
>        {
>            return false;
>        }
>
>        PpolicyConfigContainer pwdPolicyContainer =
> authenticationInterceptor.**getPwdPolicyContainer();
>
>        return ( ( pwdPolicyContainer != null )
> && ( ( pwdPolicyContainer.**getDefaultPolicy() != null )
>                || ( pwdPolicyContainer.**hasCustomConfigs() ) ) );
>    }
>
> I'm quite sure we should do that in anothr way...
>
>
>
Yes this is causing unnecessary coupling between interceptors.


>
> Right, now, I'm experimenting, moving each interceptors into a dedicated
> project (under apacheds/interceptors/authn, ...) to see what are the
> impacts.


Good idea this should clean things up and show us clearly what the cross
interceptor dependencies are.


> I'll come back with some more informations when I'll have a clear vision
> about the impacts.
>
>
Thank you,
Alex

Mime
View raw message