directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
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:44:06 GMT
On Tue, Apr 19, 2011 at 11:55 PM, Emmanuel Lecharny <> wrote:
> 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.
didn't get this, we already have in the DefaultDirectoryServ*ice*
>> 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.
it is good to have there but I didn't like the way it has to be
injected, something like
AuthenticationInterceptor authInterceptor = (
AuthenticationInterceptor ) dirService.getInterceptor(
AuthenticationInterceptor.class.getName() );
// then inject
> What would be the impact in the current code if we do that ?
am currently evaluating another thought I have, i.e to fix
PasswordPolicyException class which contains reference
to PasswordPolicyErrorEnum and this is the class which makes us to
depend on the codec-extras, removing the reference
to PasswordPolicyErrorEnum should fix the issue.

will apply this idea and see how it goes

Kiran Ayyagari

View raw message