+1 from me too. I think its better to break stuff now when we still have a excuse (hey, it ain't 1.0 yet) than post 1.0.
-tim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Krueger Sent: Thursday, November 17, 2005 10:01 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface lol Sorry Scott :) When Ben puts it like that I gotta agree hehe. +1 On 11/17/05, Dmitriy Kopylenko <[EMAIL PROTECTED]> wrote: > +1 also > > Darrell Kundel wrote: > +1 > > I support the change, it makes more sense to me. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf > Of Ben Alex > Sent: Thursday, November 17, 2005 9:23 AM > To: acegisecurity-developer@lists.sourceforge.net > Subject: Re: [Acegisecurity-developer] Proposal: Rename > AuthenticationDao interface > > Ray Krueger wrote: > > > You currently have an AuthenticationDao that successfully returns a > UserDetails instance that is built up by your four database scheme > now, correct? The whole point of the AuthenticationDao is to build a > UserDetails instance, by whatever means necessary. So, no, users like > you should do exactly what you're doing. I don't see a reason for you > two implement a new AuthenticationProvider, unless the > DaoAuthenticationProvider is not meeting you're needs. > > > > The one and only method defined by AuthenticationDao is: > > public UserDetails loadUserByUsername(String username) throws > UsernameNotFoundException, DataAccessException; > > AuthenticationDao is used variously within the system: > > Implementation: JdbcDaoImpl > Implementation: InMemoryDaoImpl > User: DaoAuthenticationProvider > User: DaoCasAuthoritiesPopulator > User: DaoX509AuthoritiesPopulator > User: DigestProcessingFilter > User: TokenBasedRememberMeServices > User: SwitchUserProcessingFilter > > AuthenticationDao is presently found in the > org.acegisecurity.providers.dao package. Given only the first three > classes above are actually in that package or a subpackage, perhaps > AuthenticationDao should be moved to a higher-level package to reflect > its broader use in five other areas of the framework. We faced a similar > > transition for UserDetails itself, from the DAO package to the top-level > > package for a similar reason. > > Whilst it's mostly semantics, the other side is clarifying relationships > > and scope of services within the framework. Perhaps we should rename > org.acegisecurity.providers.dao.AuthenticationDao to > org.acegisecurity.UserDetailsService. It will mean that > most users have > to make a fairly minor change > to the interface they're implementing in their AuthenticationDao > implementations, but aside from that it will be transparent. If we do > this, it might even be better to make an org.acegisecurity.userdetails > package, to hold UserDetails, User, UserDetailsService and the two > implementations listed above. At least we'd be emphasising "these > classes can be used anywhere within the framework or by your code" - not > > just for DaoAuthenticationProvider. > > Anyhow, I note the current responses consider this mostly a semantics > issue, but I tend to see where Scott's coming from regarding clarifying > architectural use and layering. We can make these moves with losing > revision history (I feel game - I'll log another SF CVS job! :-) ). And > users are already going to be *having* to change the import of their > AuthenticationDao implementations anyway, due to the package rename in > SEC-104. > > Thoughts? > > Cheers > Ben > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_idv28&alloc_id845&op=click > _______________________________________________ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
