On Tue, Apr 19, 2011 at 9:52 PM, Emmanuel Lecharny <[email protected]> wrote: > As a second thought, it's not *that* easy. > > The PPolicy does not belongs to core-api, that's granted, but in fact, it's > around for more than one year. > > Here is what I suggest : > - first, I would keep the current commit there. Reverting would harm the > feature, and it does not buy time > - second, and this is critical, we have to create a JIRA about moving this > part of the code out of the API > - third, as soon as we get a 1.0.0-M3 release (ie, at the end of this week > if all goes well), we can start thinking about how to get rid of PPolicy > code in core-api, to move it to core > > The interaction with the authn interceptor is huge, and I think at some > point, we also have some interaction with the DirectoryService (config, > etc). > > What I mean is that it's not a sudden mess, it's growing for more than one > year, and we just realized that now. > > Time to cleanup ! > > thoughts ? > > > On 4/19/11 4:29 PM, Pierre-Arnaud Marcelot wrote: >> >> On 19 avr. 2011, at 16:21, Emmanuel Lecharny wrote: >> >>> On 4/19/11 4:18 PM, Pierre-Arnaud Marcelot wrote: >>>> >>>> Hi Alex, >>>> >>>> On 19 avr. 2011, at 16:02, Alex Karasulu wrote: >>>> >>>>> Please revert putting this into the core-api: this functionality should >>>>> be loaded when needed as an extra rather than a core function of the >>>>> server. >>>> Thanks for reporting this, am not aware of and didn't realize that the dependency I have added has so many hidden issues >>>> I'm afraid, at the moment, there's no easy way to avoid putting it there >>>> and having the dependency on the extras jar. We lack, in the server, the >>>> same kind of support for extras you built in Shared. >>> >>> This can most certainly be put in core, not in core-api. Core-api is only >>> supposed to expose what is necessary to create the server, it's not supposed >>> to contain any impl. >> >> Yeah, OK. >> I see the point. You're right. >> Core is probably a better place. >> >> Regards, >> Pierre-Arnaud >> >>> -- >>> Regards, >>> Cordialement, >>> Emmanuel Lécharny >>> www.iktek.com >>> >> > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
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) 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. 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. So my decision back then was purely based on these facts, not merely an act of thoughtless dumping of few object references in DS just because it was there. Having said that, if people think that this commit should be reverted have no problem in doing that. -- Kiran Ayyagari
