On Thu, Jan 12, 2012 at 6:21 PM, Alex Karasulu <akarasulu@apache.org> wrote:


On Thu, Jan 12, 2012 at 3:45 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
On 1/12/12 2:01 PM, Alex Karasulu wrote:
On Tue, Jan 10, 2012 at 2:33 AM, Göktürk Gezer<gokturk.gezer@gmail.com>wrote:

Hi Again,

It seems lots of things are structured like that. Partitions,servers are
all have inner entries.There are partition-indexes and transports those
have same problem. I must develop some way to allow such structure.
Component-hub must have component type specific code to handle these
things. So i'll work on that before everything. But you can still say if
Authenticators must be extensible....

Regards,
Gokturk


Hi All,

Gokturk and I had a discussion yesterday regarding this topic. Basically
authenticators and password policies can be considered top level
configurable elements unlike indices for example that are specifically tied
to their partitions.

Authenticator are pluggable elements. PPolicy is a bit different, as we can't plug  a new PPolicy element, we can just modify its configuration.


Makes no difference but as you say below we do want to enable and disable it too.
 
We should make the distinction between those two kinds of things. Now, the question would be : should we allow the user to uninstall the PPolicy module ? I tend to think that it would be a good idea, for those who would like to embed a minimal server.


+1 regarding making it optional and the default is not to enable PP module IMO.
 



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 think so)

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?
 

The
AuthenticationInterceptor just happens to be where functionally their
maintenance made sense in the past. This might change and we might manage
these in the DirectoryService to denote their first class component status.
However PPs and Authenticators are clearly different from a Partition's
Index which is really tied to the partition where as these components are
not really tied the AuthenticationInterceptor.
At some point, we could perfectly well make the PPolicy an interceptor, instead of make it be a part of the AuthenticatorInterceptor. IMHO, it would be easier. Then disabling it would be just a matter of not loading the PPolicyInterceptor bundle at all.


That would make the AI smaller and easier to manage.
 
+1
 
+1 absolutely here, i belive PPolicy functionality can be expressed as Interceptor more efficiently. It is not meant to be more than one, and meant to be configurable, sounds like an interceptor. 



I think this makes me believe that the AuthenticationInterceptor should not
manage these components but just leverage them by accessing them from the
DirectoryService. The DirectoryService should really manage these top level
components.

Thoughts?

So let me sumup how I see those components being used in the server. Not sure it's very different with what you have in mind :
- we should have a PPolicyInterceptor, a bundle that must be loaded in order to be used. It will of course be configured. This should be a standalone bundle.

Just to shed light on terminology here, not every component has to have its own bundle. A bundle can expose more than one component. One component per bundle is the situation for interceptors but it may not be for other types. For example some Partition implementation can expose its Partition and Index implementation from one bundle. 

So removing configuration entry for some component must be our way to disable it.


+1
+1 
 
- the AuthenticatorInteceptor is also a standalone bundle, with some configuration.

+1
+1 
 
- the Authenticators are standalone bundles that are loaded by 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.


The case in here is the Authenticators will have their own life without being bound to AuthenticatorInterceptor. All AuthenticatorInterceptor have to do is to have something like: 

@Requires
private Set<Authenticator> authenticators;

in its code and all active Authenticator implementations will be injected to "authenticators" Set.
 

Partially in line with my thoughts. The configurations for the Authenticators should not be under the AuthenticationInterceptor. The Authenticators should be managed and configured under the DirectoryService. The AuthenticationInterceptor uses/refers to these Authenticators that are managed under the DS.
 
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.

-- 
Best Regards,
-- Alex