Just to get the final word - the "smaller frequency of interacting with a SecurityManager" is also a reason for why renaming it wouldn't be that big of a deal. I understand the backwards compatibility concerns, but from my experience (on both open source and teeth) is these things continue to be a like the sore tooth that you should have gone for dentist years ago. It doesn't cause harm in your daily life, but you know it's there and occasionally it reminds you a bit stronger; or from time to time new users will be asking for the same question. So typically, it's better to take the hit early on when it's still easier (and you don't have to pull the whole tooth out). For those extending the SecurityManager it's a simple matter to adjust their code. That said, naming of that class is unfortunate but I agree it really isn't a huge deal.
Kalle On Thu, Feb 19, 2009 at 6:31 AM, Les Hazlewood <[email protected]>wrote: > 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 > > > > > > > > >
