also going to remind that the authenticate method within the ASM should be deprecated as it is replaced by authenticate_account
On Sat, Aug 1, 2015 at 8:49 PM, Darin Gordon <[email protected]> wrote: > 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 >> > > > >> > > >> > >> > >
