SecurityManager

["Alan D. Cabrera" <li...@toolazydogs.com>]

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

Re: SecurityManager

[Kalle Korhonen <ka...@gmail.com>]

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 <lh...@apache.org>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 <
> kalle.o.korhonen@gmail.com
> > 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 <list@toolazydogs.com
> > >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
> > >
> > >
> >
>

Re: SecurityManager

[Jeremy Haile <jh...@fastmail.fm>]

I don't think it's a high priority but in those rare cases where you  
do interact with it, it's annoying.  Maybe before we go to 1.0, we  
just rename it to JSecurityManager.  That would be my vote.


On Feb 19, 2009, at 9:43 AM, Emmanuel Lecharny wrote:

> Hi,
>
> On Thu, Feb 19, 2009 at 3:31 PM, Les Hazlewood  
> <lh...@apache.org> wrote:
> <snip/>
>> 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 ;)
>
> I would tend to think that unless you have to write some ClassLoader,
> Securitymanager is just a class you are likely to go through only
> while stepping into a new Something() during a debugging session. So I
> don't think that the name collision is not such a burden.
>
>>
>> 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.
>
> JSecurityManager could be ok too. But I would not jump into such a
> renaming right now, as there is an existing code base, and as those
> who are likely to mess with the Sun SecurityManager are also likely to
> understand the difference. It's not like you have redefined a String
> class :)
>
> Just my 2cts...
>
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com

Re: SecurityManager

[Emmanuel Lecharny <el...@apache.org>]

Hi,

On Thu, Feb 19, 2009 at 3:31 PM, Les Hazlewood <lh...@apache.org> wrote:
<snip/>
> 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 ;)

I would tend to think that unless you have to write some ClassLoader,
Securitymanager is just a class you are likely to go through only
while stepping into a new Something() during a debugging session. So I
don't think that the name collision is not such a burden.

>
> 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.

JSecurityManager could be ok too. But I would not jump into such a
renaming right now, as there is an existing code base, and as those
who are likely to mess with the Sun SecurityManager are also likely to
understand the difference. It's not like you have redefined a String
class :)

Just my 2cts...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: SecurityManager

[Les Hazlewood <lh...@apache.org>]

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 <kalle.o.korhonen@gmail.com
> 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 <list@toolazydogs.com
> >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
> >
> >
>

Re: SecurityManager

[Kalle Korhonen <ka...@gmail.com>]

(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 <li...@toolazydogs.com>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
>
>