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
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.
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
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.
Software consultant | Author of Seam in Action
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.