5:44 p.m.
Is it really necessary to deprecate get/setUsername() and
get/setPassword() on Identity? I understand the benefits of having a
Credentials component to hold this information, and that it can be
swapped out, but I don't see why the pass through methods on Identity
cannot be treated as convenience methods. I feel like we are going to
cause a lot of people to go and change their applications for no
reason if they are fine with their current authentication setup.
Again, I am thrilled about the new security stuff. I'm just want to
make sure we don't step on the toes of current rollouts.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
6:08 p.m.
Those methods are redundant now, which is why I deprecated them.
However I do agree that we don't want to cause people to change their
applications for no reason, so with that in mind there's no reason why
we can't leave them in there for the next 5 years or however long we
want. I prefer though that new developers use the Credentials component
instead (it's more logically correct), which is why I want to steer them
away from using Identity via the @Deprecated methods.
Dan Allen wrote:
Is it really necessary to deprecate get/setUsername() and
get/setPassword() on Identity? I understand the benefits of having a
Credentials component to hold this information, and that it can be
swapped out, but I don't see why the pass through methods on Identity
cannot be treated as convenience methods. I feel like we are going to
cause a lot of people to go and change their applications for no
reason if they are fine with their current authentication setup.
Again, I am thrilled about the new security stuff. I'm just want to
make sure we don't step on the toes of current rollouts.
-Dan
7:23 p.m.
I'm totally with you on steering the new developers. I guess we could
be like Sun and never remove a deprecated method. Many IDEs just take
the deprecated hint too far and make it look near like a compilation
error. Perhaps what we really want is just to encourage developers to
use credentials, but not force their hand. We can yell at them in the
documentation ;)
-Dan
On Sun, Jun 8, 2008 at 7:08 PM, Shane Bryzak <shane.bryzak(a)jboss.com> wrote:
Those methods are redundant now, which is why I deprecated them.
However I
do agree that we don't want to cause people to change their applications for
no reason, so with that in mind there's no reason why we can't leave them in
there for the next 5 years or however long we want. I prefer though that
new developers use the Credentials component instead (it's more logically
correct), which is why I want to steer them away from using Identity via the
@Deprecated methods.
Dan Allen wrote:
>
> Is it really necessary to deprecate get/setUsername() and
> get/setPassword() on Identity? I understand the benefits of having a
> Credentials component to hold this information, and that it can be
> swapped out, but I don't see why the pass through methods on Identity
> cannot be treated as convenience methods. I feel like we are going to
> cause a lot of people to go and change their applications for no
> reason if they are fine with their current authentication setup.
>
> Again, I am thrilled about the new security stuff. I'm just want to
> make sure we don't step on the toes of current rollouts.
>
> -Dan
>
>
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:31 a.m.
I'm totally with you on steering the new developers. I guess we
could
be like Sun and never remove a deprecated method. Many IDEs just take
the deprecated hint too far and make it look near like a compilation
error. Perhaps what we really want is just to encourage developers to
use credentials, but not force their hand. We can yell at them in the
documentation ;)
@Deprecation is the most prominent way of yelling about such changes.
Noone reads docs anywhere.
/max
-Dan
On Sun, Jun 8, 2008 at 7:08 PM, Shane Bryzak <shane.bryzak(a)jboss.com> wrote:
> Those methods are redundant now, which is why I deprecated them. However I
> do agree that we don't want to cause people to change their applications for
> no reason, so with that in mind there's no reason why we can't leave them in
> there for the next 5 years or however long we want. I prefer though that
> new developers use the Credentials component instead (it's more logically
> correct), which is why I want to steer them away from using Identity via the
> @Deprecated methods.
>
> Dan Allen wrote:
>>
>> Is it really necessary to deprecate get/setUsername() and
>> get/setPassword() on Identity? I understand the benefits of having a
>> Credentials component to hold this information, and that it can be
>> swapped out, but I don't see why the pass through methods on Identity
>> cannot be treated as convenience methods. I feel like we are going to
>> cause a lot of people to go and change their applications for no
>> reason if they are fine with their current authentication setup.
>>
>> Again, I am thrilled about the new security stuff. I'm just want to
>> make sure we don't step on the toes of current rollouts.
>>
>> -Dan
>>
>>
>
>
>
2:44 a.m.
On Jun 09, 2008, at 09:31 , Max Rydahl Andersen wrote:
> I'm totally with you on steering the new developers. I guess
we could
> be like Sun and never remove a deprecated method. Many IDEs just take
> the deprecated hint too far and make it look near like a compilation
> error. Perhaps what we really want is just to encourage developers to
> use credentials, but not force their hand. We can yell at them in the
> documentation ;)
@Deprecation is the most prominent way of yelling about such changes.
Noone reads docs anywhere.
Yes, and for that reason never use @Deprecated without hints as to
what to do about it. Which is the actual problem with the current
changes to Identity.
5:57 a.m.
Christian Bauer wrote:
On Jun 09, 2008, at 09:31 , Max Rydahl Andersen wrote:
>> I'm totally with you on steering the new developers. I guess we could
>> be like Sun and never remove a deprecated method. Many IDEs just take
>> the deprecated hint too far and make it look near like a compilation
>> error. Perhaps what we really want is just to encourage developers to
>> use credentials, but not force their hand. We can yell at them in the
>> documentation ;)
>
> @Deprecation is the most prominent way of yelling about such changes.
>
> Noone reads docs anywhere.
Yes, and for that reason never use @Deprecated without hints as to
what to do about it. Which is the actual problem with the current
changes to Identity.
Pretty sure all the deprecated methods have @see tags now.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
6021
days inactive
6022
days old
5 comments
4 participants
participants (4)
-
Christian Bauer -
Dan Allen -
Max Rydahl Andersen -
Shane Bryzak