I took another look at the JdbcDaoImpl (and JdbcExtendedDaoImpl). I think I understand what I was missing before, and I have a suggestion to add as well.
In JdbcDaoImpl, the default query strings are static string parameters. In the constructor of JdbcDaoImpl, the default strings are copied to the query string parameters that are called by the internal sql mapping classes, in their constructors. So if my understanding is correct, the object instance is created first, meaning the internal classes are initially created w/ the default strings, before any getter/setters are called by Spring. So what I was likely missing before was the need to set 'init-method="initDao"' in the spring configuration to make sure that the initDao() method was called after spring was finished, to re-initialize the internal sql mapping objects after the new sql query strings are set by spring. So if this init method is not called, then attempting to use it will result in the class ignoring the set query strings, and using the default ones. So this should probably be explicitly documented in the JavaDoc that if you are setting the query strings, you need to call 'initDao()' as well. Or a different mechanism used to detect changes and remove the dependency on 'initDao'. The other thing I wanted to bring up, was that JdbcExtendedDaoImpl introduces a new method: String convertAclObjectIdentityToString(AclObjectIdentity aclObjectIdentity) Which converts the aclObjectIdentity argment to a string that it can use to query the database. If you look at JdbcDaoImpl, in the 'getAcls(AclObjectIdentity aclObjectIdentity)' method, you'll find that theres a section of code that does virtually the same thing. So I would think it'd be cleaner code-wise and consistency for the 'convertAclObjectIdentityToString' method to be moved to JdbcDaoImpl, and used to implement the conversion to string in 'getAcls' as well. This would also make it easier to extend the class and still invoke the superclass 'getAcls' when working with ACLs that need to be converted to different string formats than the standard used in Acegi. -tim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Kettering Sent: Monday, August 22, 2005 6:42 PM To: acegisecurity-developer@lists.sourceforge.net Subject: RE: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl I believe it does not work if you extend the class itself, due to how the internal MappingSqlQuery classes that implement those queries set/reference themselves. Seems like the default strings get applied via constructor before the setter methods are called via spring. I am not 100% on this. It was a while ago, and I may have done something incorrectly. This kind of pertains to my earlier email about how I found it difficult to extend JdbcDaoImpl (and the extended Dao as well), in a clean fashion. If I have some time tomorrow, I can try to investigate this and report with more conclusive results. -tim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Monday, August 22, 2005 6:11 PM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl Pascal Gehl wrote: >Hi, > >I've written a blog entry on how to extend JdbcDaoImpl. >I would appreciate guru's to check if I don't misunderstood it. > >http://www.jroller.com/page/paskos?entry=acegi_using_a_custom_select > > Hi Pascal You should have been able to use setAuthoritiesByUsernameQuery(String) and setUsersByUsernameQuery(String) on JdbcDaoImpl. Did that not work? Cheers Ben ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
