As much as I would like to get these changes in now, your argument for postponing is a good one in light of the package changes that we must make. I guess the only other argument would be to do the package changes now and make this release our first "apache" release.
On Tue, Jun 24, 2008 at 9:40 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > Let me summarize the previously agreed upon solution: > > The idea was to have two parent interfaces AuthenticationInfo and > AuthorizationInfo, which would be used in the Authentication and > Authorization subsystems only (i.e. no compile-time dependency between > the two), which would be quite nice in maintaining separation of > concerns. The Account interface would then just become a sub > interface of both, to make it super easy for end-users to just > implement one interface and be be done with it. > > Now the challenge: I did a search for where the Account interface is > being used - there are over 130 usages. > > The problem is that every place in the Authentication subsystem that > references Account would have to be refactored into using > AuthenticationInfo. Account would essentially be a util class, or > maybe just visible to the realm package and not anywhere else. > > While the IDE can refactor this quite easily and I don't foresee any > problems there, this touches _A LOT_ of code. My preference is to > just get 0.9 final out with the way things are now and do this kind of > change once we move the codebase into the ASF incubator SVN repo. My > thinking is that if such a change would be viewed as invasive by > end-users, then it is better to introduce such change when we switch > over to the package structure of org.apache.jsecurity.*. That is, it > is much better to just get any invasive changes out at the same time > in one lump to minimize the perceived overhead instead of trickling > potential causes of irritation over time. > > Any thoughts? >
