On Thu, Jan 12, 2012 at 7:26 PM, Emmanuel Lécharny <email@example.com>
On 1/12/12 5:21 PM, Alex Karasulu wrote:
Although Authenticators and PasswordPolicies are managed under the
AuthenticationInterceptor they are top level elements.
Can you clarify what you mean by TL elements ? Are they bundles ? (I do
I mean this in terms of configuration nesting. For example in the
configuration DIT area these should not be found to be configurable under
the authentication interceptor but should be things we can configure at the
top level under the directory service.
Does this shed more light on my terminology?
Agreed. I don't think I mentioned this part, so thanks for making it crystal clear.
- the Authenticators are standalone bundles that are loaded by the
Partially in line with my thoughts. The configurations for the
AuthenticatorInteceptor, depending on the AuthenticatorInteceptor
configuration. We should be able to load/decommision an Authenticator on
the fly, without having to stop the server.
Authenticators should not be under the AuthenticationInterceptor.
Kruta (means cool in Russian)
Authenticators should be managed and configured under the DirectoryService.
The AuthenticationInterceptor uses/refers to these Authenticators that are
managed under the DS.
Yep. So we should move the Authenticator config elsewhere (ie, not under the AuthenticationInterceptor). This way, they can be used by someone who wants to develop another interceptor.
Does this make sense ? Does it aligns well with what Gokturk is working on
Almost just a simple difference in our thoughts but really nothing at all.
I just think think about interceptors as a mechanism to inject aspects and
functionality. The interceptor itself need not manage the configuration of
the aspect.This can be done outside the interceptor. The interceptor is
there to just do the bidding of the aspect and apply it to the invocation.
We should also create a PPolicy interceptor (just as a reminder).
I suggest we create JIRAs for those tasks, to be sure we don't forget to do that.
OK I'll add the issues.
IMO, we can even make those changes in trunks, and inject the changes into the OSGi branch, because it's orthogonal.
Thanks for the clarification !
Thank you as well.