Thanks guys,
I'll propose we leave this open for comment one more day and if
there aren't any objections I'm willing to make the code and documentation
changes this weekend.
Scott
> -----Original Message-----
> From: Tim Kettering [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 17, 2005 10:21 AM
> To: [email protected]
> Subject: RE: [Acegisecurity-developer] Proposal: Rename
> AuthenticationDao interface
>
>
> +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: [email protected]
> 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: [email protected]
> > 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
> > [email protected]
> > 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
> > [email protected]
> > 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
> [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
