Yeah, the idea for deprecating it is that the current DefaultSecurityManager implementation suffers from excessive subclassing, as did other Shiro components in 1.x. Shiro 2.x favors much more the cleaner OO approach of 'composition over inheritance' where functionality is delegated to components rather than relying on subclasses (and making things more pluggable / flexible in the process).
ApplicationSecurityManager is really just a lateral move of the same behavior of DefaultSecurityManager, but in a different class name so dramatic class hierarchy changes don't break people currently compiling against the DefaultSecurityManager hierarchy. So there are two approaches for a 2.0.0 final release that I'm thinking about. @Deprecate DefaultSecurityManager now to ensure people don't use it anymore and then: 1. delete it permanently, or 2. copy the ApplicationSecurityManager logic into DefaultSecurityManager at the last minute right before 2.0.0 (making DSM backwards incompatible) and then deleting ApplicationSecurityManager. Both approaches are backwards incompatible, but I prefer #2 just because DefaultSecurityManager is well-known enough such that not having it might have more problems than the compiler errors from having different behavior. I'm trying really hard to keep all things backwards compatible, as I think that is a worthwhile goal in a well-established project like Shiro, but sometimes 'cleaning house' does more good for the community moving forward than having weird / less-well-designed things stick around and potentially cause confusion. Thoughts? Cheers, Les On Sat, Aug 1, 2015 at 2:11 PM, Darin Gordon <[email protected]> wrote: > Les > > Would you please confirm that the DefaultSecurityManager is to be > deprecated as of 2.0 , given the ApplicationSecurityManager ? the > DefaultSecurityManager hasn't been marked @deprecated yet and so I wanted > to confirm > > > thanks > > DG >
