Re: [Acegisecurity-developer] (no subject)
That's the correct URL for the core, https://src.springframework.org/svn/spring-security/branches/2.0.x-branch is the url for the whole branch. There's a SSL certificate mismatch - that's probably confusing your client. I use Eclipse and it prompted me to keep the mismatched certificate and I'm able to see the whole repo. -- Burt On Monday 22 December 2008 8:28:24 pm Andrew Wang wrote: Hello, Can somebody tell me how to build acegi? I am trying to follow this link http://static.springframework.org/spring-security/site/building.html Build immediately i found the url is wrong, I use browser to figure out that should be https://src.springframework.org/svn/spring-security/branches/2.0.x-branch/core/ But still svn client can not reach the url, some thing wrong with my svn? What's a proper step by step instruction? Thanks Andrew -- ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the security patterns: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecur ityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulDefi nitionSource constructor-arg type=java.lang.String value /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER /value /constructor-arg /bean The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to all methods. But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecurityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocatio nDefinitionMap property name=objectDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR /value /property /bean But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry [EMAIL PROTECTED] wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: property name=readMethods value=GET,HEAD,OPTIONS,PROPFIND/ property name=writeMethods value=POST,PUT,DELETE,PROPPATCH,LOCK/ and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Home:
Re: [Acegisecurity-developer] (no subject)
Nice work Chris, any chance you could open some Jiras on that? On 8/23/07, Chris Berry [EMAIL PROTECTED] wrote: I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the security patterns: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecur ityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulDefi nitionSource constructor-arg type=java.lang.String value /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER /value /constructor-arg /bean The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to all methods. But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecurityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocationDefinitionMap property name=objectDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR /value /property /bean But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry [EMAIL PROTECTED] wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: property name=readMethods value=GET,HEAD,OPTIONS,PROPFIND/ property name=writeMethods value=POST,PUT,DELETE,PROPPATCH,LOCK/ and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using
Re: [Acegisecurity-developer] (no subject)
Done http://opensource.atlassian.com/projects/spring/browse/SEC-531 Cheers, -- Chris On Aug 23, 2007, at 1:44 PM, Chris Berry wrote: Will do. It sure would be nice to incorporate this back into Acegi. IMHO, REST will (or is ;-) supplant all other web service methodologies. Acegi should support it natively. I need to soon do the same work for securing methods by Http Method Cheers, -- Chris On Aug 23, 2007, at 1:16 PM, Ray Krueger wrote: Nice work Chris, any chance you could open some Jiras on that? On 8/23/07, Chris Berry [EMAIL PROTECTED] wrote: I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the security patterns: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecur ityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulDefi nitionSource constructor-arg type=java.lang.String value /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER /value /constructor-arg /bean The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to all methods. But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecurityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocat ionDefinitionMap property name=objectDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR /value /property /bean But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry [EMAIL PROTECTED] wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: property name=readMethods value=GET,HEAD,OPTIONS,PROPFIND/ property name=writeMethods value=POST,PUT,DELETE,PROPPATCH,LOCK/ and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list
Re: [Acegisecurity-developer] (no subject)
Agreed :) And thanks! On 8/23/07, Chris Berry [EMAIL PROTECTED] wrote: Done http://opensource.atlassian.com/projects/spring/browse/SEC-531 Cheers, -- Chris On Aug 23, 2007, at 1:44 PM, Chris Berry wrote: Will do. It sure would be nice to incorporate this back into Acegi. IMHO, REST will (or is ;-) supplant all other web service methodologies. Acegi should support it natively. I need to soon do the same work for securing methods by Http Method Cheers, -- Chris On Aug 23, 2007, at 1:16 PM, Ray Krueger wrote: Nice work Chris, any chance you could open some Jiras on that? On 8/23/07, Chris Berry [EMAIL PROTECTED] wrote: I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the security patterns: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecur ityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulDefi nitionSource constructor-arg type=java.lang.String value /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER /value /constructor-arg /bean The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to all methods. But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecurityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocationDefinitionMap property name=objectDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR /value /property /bean But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry [EMAIL PROTECTED] wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: property name=readMethods value=GET,HEAD,OPTIONS,PROPFIND/ property name=writeMethods value=POST,PUT,DELETE,PROPPATCH,LOCK/ and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/
Re: [Acegisecurity-developer] (no subject)
Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecurityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource ref=filterDefinitionMap / /bean bean id=filterDefinitionMap class=com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocationD efinitionMap property name=objectDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR /value /property /bean But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry [EMAIL PROTECTED] wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: property name=readMethods value=GET,HEAD,OPTIONS,PROPFIND/ property name=writeMethods value=POST,PUT,DELETE,PROPPATCH,LOCK/ and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR -- --- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
Yes, that would work. Thanks. -tim Hi Tim Yes, the design does require the DAO provider know how to interpret the presented AclObjectIdentity. As you know, JdbcDaoImpl (and any BasicAclDao for that matter) needs to be able to create BasicAclEntry[]s in response to the DAO request. Each BasicAclEntry has getAclObjectIdentity() and getAclObjectParentIdentity() methods, meaning the BasicAclDao needs to convert from row-data expressing this information into a new object instance. So, whilst your proposal caters for object - database mapping, it doesn't address database - object mapping. I guess we could offer a pluggable interface within JdbcDaoImpl which does this conversion. ie: public interface AclObjectIdentityStringResolver { public AclObjectIdentity convertToIdentityObject(String identity); public String convertToIdentityString(AclObjectIdentity aclObjectIdentity); } Would that address your needs? Ben --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
[EMAIL PROTECTED] wrote: Hello ! I am new to this framework, I have changed the default queries in net.sf.acegisecurity.providers.dao.jdbc.jdbcDaoImpl, and now I want to compile the project again. I guess it should be a simple task to use ant build but It seems that with the distribution file acegi-security-0.6-with-dependencies.zip the project.properties and build.properties are missign, so apparently I cannot compile the project. any ideas or any clues I will highly appreciate your response. Regards, Sami Ather Hi Sami Apologies for that. It's actually not come up so far, as everyone running builds performs a CVS checkout. I've just made a change to the Ant build release target so it's included in future releases. As for the JdbcDaoImpl, any reason you wouldn't subclass it or use its setMapping() or setQuery() methods? We've designed JdbcDaoImpl to be easily customisable through these extension points, so please let us know if it doesn't meet your needs in some way. Best regards Ben --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer