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 ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
