We thought about that in the past when naming it and decided to keep it for
fear of the backwards-incompatible changes it would force on framework
developers - i.e. the Grails plugin and others.
I think in practice it hasn't been a big deal really. It is relatively rare
that a JSecurity user should interact with the SecurityManager directly. In
the few cases that they do, manually adding the package import seems to be
ok. The JSecurity development team is the one that has to deal with this
more than anyone else because of our own code references. I at least
haven't found it distracting enough for me to change the name.
My own opinion is that, due to the smaller frequency of interacting with a
SecurityManager directly (vs. SecurityUtils.getSubject() ), and the that its
not much of burden. But that's just my opinion ;)
If the community feels that it should be changed to something else, I'm open
to the change. Maybe JSecurityManager if you want to avoid the *Service ->
*Manager renaming.
If we change the project name, I think that would be the only time we should
introduce such a name change, say to {projectName}SecurityManager, since
end-users and framework developers will already need to execute
search-and-replace.
On Thu, Feb 19, 2009 at 12:22 AM, Kalle Korhonen <[email protected]
> wrote:
> (non-binding) +1 from me, I thought it was a bit confusing as well.
> Considering it doesn't enforce to authenticate or authorize, but rather
> makes it possible for other code to do so by providing the necessary
> interface, SecurityService might be appropriate. However, *Manager naming
> is prevalent, would need to change all of them.
>
> Kalle
>
>
> On Wed, Feb 18, 2009 at 9:01 PM, Alan D. Cabrera <[email protected]
> >wrote:
>
> > Just a thought. Should we rename this class? The fact that it's the
> same
> > name as java.lang.SecurityManager makes me a little uncomfortable.
> >
> > Again, just a thought.
> >
> >
> > Regards,
> > Alan
> >
> >
>
