shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darin Gordon <dar...@gmail.com>
Subject Re: DefaultSecurityManager deprecated as of 2.0?
Date Sun, 02 Aug 2015 00:49:17 GMT
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 <lhazlewood@apache.org> 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 <darinc@gmail.com> 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 <lhazlewood@apache.org>
> > 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 <darinc@gmail.com> 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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message