On Mon, Jan 10, 2011 at 2:22 PM, Les Hazlewood <[email protected]> wrote: > Can we guarantee that if a user upgrades from 1.1 to 1.2 their > existing code and/or config won't break due to this change? If not, I > question the need for this to occur right now. Sure, it's not an > ideal thing having Realm extend Authorizer, but if it breaks code, I > don't know what the hurry would be.
Hey Les, sure, I did think about it. I can only "virtually guarantee" - as you say, most users have extended AuthorizationRealm anyway where everything works as before. Only if they've implemented Realm directly, they'd have to explicitly Authorizer as the other implemented interface. I don't think you can create configuration only in a way that would break this. I'm of the opinion that any code smell should be addressed as soon as possible to prevent it from becoming a bigger issue. This is easy to document in the upgrade notes since we didn't change any of the actual interfaces. It fails fast and is easy to correct. If we didn't do it now, it would have to wait for till unplanned and unscheduled 2.x and for such a small upgrade issue, I think it's much better to encourage users to upgrade and keep up with the api changes in small steps. > The fact that Realms have always been able to perform both > authentication and authorization has been true for a very long time. > Removing it for a minor release sounds a little hasty to me. I'm not > questioning the change - just the timing. But the AuthenticatingRealm doesn't imply that. You know an authenticating only realm and an ability to differentiate between authenticating only and authorizing realms makes sense. We could of course keep the other changes I made and add Authorizer back to the top - but since there's no way to indicate it as deprecated (unless we introduced a new base interface replacing Realm, which would be far worse), it seems to me repositioning the interface in the inheritance hierarchy is still a much better option. Kalle
