You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/05/14 03:54:10 UTC
Re: cvs commit:
jakarta-turbine/src/java/org/apache/turbine/util/security GroupSet.java
on 5/13/01 6:36 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> Travis Low wrote:
>>
>> jon@apache.org wrote:
>>>
>>> jon 01/05/13 13:35:04
>>>
>>> Modified: src/java/org/apache/turbine/om/security Group.java
>>> TurbineGroup.java
>>> src/java/org/apache/turbine/om/security/peer GroupPeer.java
>>> UserGroupRolePeer.java
>>> src/java/org/apache/turbine/util/security GroupSet.java
>>> Log:
>>> * @deprecated Will be renamed. see:
>>> http://jakarta.apache.org/turbine/proposals/security-service.html
>>
>> Have you decided on a replacement name yet? I have some functionality I'd
>> like to add,
>> and I'd like to use the correct name. FWIW, I think "realm" is a better
>> choice, since
>> "domain" has so many other connotations.
>>
>
> Hmmm, I don't think we can actually deprecate something unless it is
> disappearing (in the case of the older Upload services), or we have a
> replacement for what we are deprecating.
>
> For the security system, I don't think we can deprecate the old
> classes until the new files are in place. Make sense?
We may not have the new files in place, but I don't want to make a 2.1b1
release tomorrow with Group in there because it will be going away.
People can still code to Group and use it until a replacement is in...
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Deprecating Security System
Posted by Jon Stevens <jo...@latchkey.com>.
on 5/13/01 7:40 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> If we are going to go that approach then everything that does not
> match the security proposal should be marked as deprecated because
> the majority of it is going away.
Ok.
I guess my point is that if we are going to make a release *knowing* that
this code is going to go away or be modified, then we should notify people
of that fact in some sort of fashion that tells people that their code that
is based on 2.1b1 isn't going to work into the future...
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Deprecating Security System
Posted by Jason van Zyl <jv...@apache.org>.
[snip]
> > Hmmm, I don't think we can actually deprecate something unless it is
> > disappearing (in the case of the older Upload services), or we have a
> > replacement for what we are deprecating.
> >
> > For the security system, I don't think we can deprecate the old
> > classes until the new files are in place. Make sense?
>
> We may not have the new files in place, but I don't want to make a 2.1b1
> release tomorrow with Group in there because it will be going away.
If we are going to go that approach then everything that does not
match the security proposal should be marked as deprecated because
the majority of it is going away.
I think we have to deprecate the security system with some consistency.
I don't actually think any of it should be marked as deprecated until
the replacement is there. Deprecation messages should point to the
prefered alternate, but the alternate doesn't exist yet. I don't think
that makes much sense.
If the two security systems are going to co-exist then shouldn't
the old system be deprecated in 2.2? People can then phase out the
old system in the 2.2 cycle and we can say it will be gone in 2.3.
>
> People can still code to Group and use it until a replacement is in...
I don't think that's standard practice: to deprecate a class with no
extant alternative. If 2.2 comes out in August
then people are going to get senseless deprecation messages for
two months. I just think it would be confusing.
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://jakarta.apache.org/commons
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org