> 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 ;) 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. Great stuff - I look forward to the other threads! Les
