On Tue, Apr 19, 2011 at 11:55 PM, Emmanuel Lecharny <[email protected]> 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
