directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: svn commit: r1095083 - in /directory/apacheds/trunk: core-api/ core-api/src/main/java/org/apache/directory/server/core/ppolicy/ core/src/main/java/org/apache/directory/server/core/authn/
Date Tue, 19 Apr 2011 18:25:54 GMT
On 4/19/11 8:07 PM, Kiran Ayyagari wrote:
> let me describe the rationale behind keeping the code in core-api
> (back then this was called 'core' and the ppolicy config class was
> added almost an year ago, what I did today was just moving a few other
> classes back at this place)

Yes, understood.
> The DirectoryService(DS) is the object which is accessible from most
> of the core so it was a natural choice by design to keep the ppolicy
> config
> inside DS cause it is easy to inject during initialization and can be
> accessed from several places (in our case we need to access it
> from AuthenticationInterceptor and AbstractAuthenticator).  A server
> can support more than one ppolicy so the container of these policies
> is also
> maintained in the DS.

I'm wondering if it wouldn't be better to have those classes available 
in the DS implementation (DefaultDirectoryServer), and how complex it 
would be.
> One alternative to the above is to use AuthenticationInterceptor to
> hold the ppolicy config, but in my view that is not the best place of
> choice.

It depends. PasswordPolicy is about authentication anyway. The problem s 
that it would make the AuthenticationInterceptor more complex, but OTOH, 
this is exactly where it used.

Plus the PPolicy config could be confined in this interceptor 
configuration, not necessarily a bad idea.

What would be the impact in the current code if we do that ?

Emmanuel L├ęcharny

View raw message