shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: DefaultSecurityManager deprecated as of 2.0?
Date Sat, 01 Aug 2015 23:49:24 GMT
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.




On Sat, Aug 1, 2015 at 2:11 PM, Darin Gordon <> 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

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