On Oct 23, 2010, at 1:08 PM, Les Hazlewood wrote: >> Customization is fine. Delegation is fine. But these capabilities don't >> require that the implementation be based on abstract classes with complex >> and brittle interactions with their implementations. I might even go so far >> as to say that extensive use of delegation via inheritance is an >> anti-pattern. > > I'll wait for the other threads, but please explain how you might do > this otherwise using the SecurityManager as an example. Maintaining a > 3000-line class is not a good option IMO (I'm sure you have great > ideas, I would just like us to not have to maintain that type of > file). > >> Also, having all those protected methods out there makes the API very >> brittle. We saw this when we converted the code to start using >> StringBuilder. > > Of all 30+ files that were changed for this, there was only one method > that ended up being backwards incompatible. That doesn't sound very > brittle to me ;)
You changed RedirectView's signature. That's not backward compatible. Again, the reason for this problem is because of the extensive use of inheritance for complex and brittle interactions with their implementations. > > But I understand your point - it's good to lock down where you can. > Most of the protected methods exist from the (very old) JSecurity days > and could use a bit of review. > >> I think Kalle and I are talking about a new architecture based on what we've >> learned so far. I'm sure 2.0 is a long way off but it doesn't hurt to chat >> about it. > > I'm all for it - I think talking about 2.x now is a good idea. One of > the big things I want to do for 2.x is split the shiro-core module > into different modules (authc, authz, etc). This will probably > involve moving some classes and packages around in order to make all > those new modules OSGi-compliant - something we can only do in a new > major release. Good stuff! Regards, Alan
