On 11/1/11 3:01 PM, Göktürk Gezer wrote:
Hi Emmanuel,
<snip/>
OTOH, we allow the admin to modify the order, simply by changing the
configuration, and it could lead to some bad bad things...
We wont let admin to change order for core ones.
Right now, this is allowed, through a configuration modification...
What if we create an implicit order by defining which interceptor is
allowed before each interceptor ? For instance, this is the default order :
1 normalizationInterceptor
2 authenticationInterceptor
3 referralInterceptor
4 aciAuthorizationInterceptor
5 defaultAuthorizationIntercepto**r
6 exceptionInterceptor
7 operationalAttributeIntercepto**r
8 keyDerivationInterceptor
9 passwordHashingInterceptor
10 schemaInterceptor
11 collectiveAttributeInterceptor
12 subentryInterceptor
13 eventInterceptor
14 triggerInterceptor
We could obtain the same order by replacing the ads-interceptororder AT by
a ads-previousInterceptor :
1 normalizationInterceptor ( previous : null )
2 authenticationInterceptor ( previous : normalizationInterceptor )
3 referralInterceptor ( previous : authenticationInterceptor )
4 aciAuthorizationInterceptor ( previous : referralInterceptor )
5 defaultAuthorizationIntercepto**r ( previous :
aciAuthorizationInterceptor, referralInterceptor ) (here, the
aciAuthorizationInterceptor may be disabled)
6 exceptionInterceptor ( previous : defaultAuthorizationIntercepto**r )
7 operationalAttributeIntercepto**r ( previous : exceptionInterceptor )
8 keyDerivationInterceptor ( previous : operationalAttributeIntercepto**r
)
9 passwordHashingInterceptor ( previous : keyDerivationInterceptor )
10 schemaInterceptor ( previous : passwordHashingInterceptor )
11 collectiveAttributeInterceptor ( previous : schemaInterceptor )
12 subentryInterceptor ( previous : collectiveAttributeInterceptor )
13 eventInterceptor ( previous : subentryInterceptor )
14 triggerInterceptor ( previous : eventInterceptor )
Now, for interceptors that has no specific requirement, we can set the
previous AT to the previous AT it will follow.
The key is that we must distinguished between critical inteceptors (the
level-1 interceptors) and others. We enforce the position only within one
level (ie, level-1 interceptors orders are checked, then level-2, then
level-3). So we can add a non critical interceptor (ie level-2 or 3) in the
chain between two critical interceptors, without creating any trouble in
the critical interceptor order : the check for level-1 interceptors' order
is done ignoring level-2 interceptors.
thoughts ?
At first i thought that linked buckets approach. This is easier to
implement and it is intuitive. By this way, 3th parties can also make their
one of custom interceptor to be dependent on the some other custom
interceptor. So that, they can create the same ordering resolution as with
the method i proposed.
But there are some problems with that approach:
* First of all we're creating an implicit dependency here. Every
interceptor in the current codebase is not mandatory. But some other custom
interceptor implementation may refer to those which are not core. If this
"noncore but apacheds-made" interceptor is missing in runtime. The ordering
is impossible. We can't even warn the user or throw exception. Because in
OSGI, everything can come and go at anytime. When we can't find the
ads-previousInterceptor at install time of particular interceptor, we can't
raise an error, we have to wait for it.But if that dependency never comes,
then we can't sort the interceptor list. Serious problem!
I see your point : the interceptors should not be responsible for their
own position in the chain. The DS should be.
* Secondly, somebody may want to write custom version of the core
interceptors. But with using linked dependencies with names, this is
impossible without changing the source code of the interceptors those are
dependent on the replaced one. That will create very big weakness on our
extendibility.
Right... Numbers are less explicit, but easier to deal with.
* And i believe, possessing abstraction of level into interceptor ordering
is good for users and custom implementors. Because that way we can say for
example, "at level1, X service is maintained", "at level2, Y service is
maintained." and so on... So that, they inject their custom interceptor to
the right level of their choice without knowing the name of the interceptor
that implemented that logic.
So again, this issues are the concern of "How much extendibility we'll
offer?" question.
The key is to not insult the future. We are targeting a 2.0, and it's
likely to be around for years. If we build a rigid server, we are
shooting ourselves in the foot.
I buy the idea that we are different kind of interceptors. The core
interceptors will be the server backbone, and we should not allow anyone
to determinate the order in which they are set. But we should allow
anyone to inject a new interceptor in the middle of this backbone. Those
injected interceptors may be placed anywhere in the chain, assuming that
it's the responsibility of the user to put it at the right place.
PS : try to 'reply list' instead of 'reply all' : I will not be added in
the list of recipients...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
