Really, just scratch the thought. The BaseDigestPasswordEncoder is simple enough in it's purpose that I can leave it alone and put all my MessageDigest stuff in it's own subclass.
On 5/30/06, Ray Krueger <[EMAIL PROTECTED]> wrote: > I looked at SEC-96 > http://opensource.atlassian.com/projects/spring/browse/SEC-96 and > thought it would be an easy thing to jump on. > The refactoring is actually very beneficial, as the Md5 and Sha > PasswordEncoder classes were basically duplicates with one word > changed (yuck). > > I've refactored that into a much more flexible situation, while > maintaining compatibility for the Md5PasswordEncoder and > ShaPasswordEncoder. The question I have though is about their super > class, BaseDigestPasswordEncoder. That class was originally abstract, > with a no constructor. I have made it regular class with a constructor > for the requried option, "algorithm". This class can now be used > stand-alone if it was ever required of it. > > As BaseDigestPasswordEncoder was an internal class, I don't think this > is a backwards compatibility issue. The two public api classes, > Md5PasswordEncoder and ShaPasswordEncoder, have not changed in > contract at all. > > Any thoughts? > _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
