Thanks for clarifying. There aren't many confusing parts of the 2.0 source other than this part since the DSM wasn't marked @deprecated, although it is and should be. :)
+1 for compositional thinking and the eventbus.. On Sat, Aug 1, 2015 at 8:29 PM, Les Hazlewood <[email protected]> wrote: > Just rename - as a delayed strategy to not break anything until _just > before_ 2.0.0 final. Basically during the 2.0.0 release process. Does > that make sense? > > On Sat, Aug 1, 2015 at 5:21 PM, Darin Gordon <[email protected]> wrote: > > > DefaultSecurityManager represents the legacy inheritance-based approach > > where as ApplicationSecurityManager represents the new composition-based > > approach. By re-naming the security manager, as you've initially done in > > v2, developers will be less likely to assume which approach is taken. In > > other words for your option #2, are you saying that you intend to just > > rename ApplicationSecurityManager to DefaultSecurityManager, or actually > > commingle code? > > > > > > > > > > > > On Sat, Aug 1, 2015 at 7:49 PM, Les Hazlewood <[email protected]> > > wrote: > > > > > 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 > > > > > > > > > >
