[Acegisecurity-developer] SEC-96 and backwards compatiblity
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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] SEC-96 and backwards compatiblity
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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Acegi Security 1.0.0 is released!
I took the freedom also to tag the source tree and bump the pom versions to 1.1.0-SNAPSHOT On 5/30/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'll take care of that On 5/30/06, Ray Krueger [EMAIL PROTECTED] wrote: Can we get the maven repos updated? Right now mvn compile fails because org.acegisecurity:acegi-security-parent:pom:1.0.0 cannot be downloaded. On 5/30/06, Mark St.Godard [EMAIL PROTECTED] wrote: Hi Ben, The configuration was referencing net.sf... some of the config was moved over to org. however not all. Including the userdetails refactoring. Plus some of the JSPs were also referencing net.sf in page imports. I am running through and testing the app right now, currently failing on a call to getPrincipal from User object... I will fix it up, retest it, run the unit testing and check in the changes. Re: the tutorial app... yeah I noticed that .. very nice... much more concise config. I am usng Spring 2.0 and I am really digging the schema-based config... I am also using MethodSecurityInterceptors using the new Aspect pointcuts. Not sure if we should also include examples of usage using Spring 2.0? I assume we need to wait for it to go final. Uri is on it...Great, I'll keep my eyes posted for acegi:config :) Cheers Mark On 5/30/06, Ben Alex [EMAIL PROTECTED] wrote: Mark St.Godard wrote: Just a note, Ben I will be updating the contacts-tiger sample project, I noticed it was not converted over. I will create an JIRA entry for myself and update this tomorow. I just checked and it looked to me like it was built for 1.0.0. What specifically wasn't converted? Also with Spring 2.0, I noticed that a jira entry was created for namespace handlers, XSD support, etc.. http://opensource.atlassian.com/projects/spring/browse/SEC-271 for those interested. If you have someone to do this fine... otherwise I can take it up... its something that I would really like to get in... and reduce some of the XML verbosity. Uri Boness has volunteered, but I'm unsure whether work has commenced. I am happy for anyone to take a look at it who has sufficient time. As for verbose XML, I'd encourage people to take a look at the new tutorial sample, which is just 148 lines of XML. This includes comments, whitespace and full support for form authentication, remember-me, anonymous and web request authorization. I think that's a pretty good base given the features, but nevertheless it will be even less with SEC-271 improvements. Cheers Ben ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
Hi, We upgraded to the 1.0 final jar the other day and things worked fine on our dev build, which uses an InMemoryDao implementation. However, last night we tried to push out a build to the client and the context will no longer start due to a NoClassDefFound in the Acegi code. (FilterBasedLdapUserSearch) I googled for the class -- org/springframework/dao/EmptyResultDataAccessException -- and it's only in Spring 2.0! I hope 1.0 final hasn't presumed that people will switch to Spring 2.0. Is there something I need to change ldap-wise when moving from 1.0 rc2 to 1.0 final? Stacktrace below. Any help greatly appreciated. Heh, this was supposed to be the real production deploy with the client hitting the system hard tomorrow morning (and needing to do some admin setup today). thanks, Ben 2006-05-31 00:34:15,900 INFO org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization started 2006-05-31 00:34:15,902 INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/totaltime] - Loading Spring root WebApplicationContext 2006-05-31 00:34:15,952 INFO org.springframework.core.CollectionFactory - JDK 1.4+ collections available 2006-05-31 00:34:15,962 INFO org.springframework.core.CollectionFactory - Commons Collections 3.x available 2006-05-31 00:34:16,119 ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'userSearch' defined in ServletContext resource [/WEB-INF/config/acegi/fragments/ldapAuthenticationProviderCommon.xml]: Class that bean class [org.acegisecurity.ldap.search.FilterBasedLdapUserSearch] depends on not found; nested exception is java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.springframework.util.ClassUtils.forName(ClassUtils.java:109) at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:65) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:466) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:432) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:347) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.importBeanDefinitionResource(DefaultXmlBeanDefinitionParser.java:374) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:338) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.importBeanDefinitionResource(DefaultXmlBeanDefinitionParser.java:374) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:338) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at
Re: [Acegisecurity-developer] Acegi Security 1.0.0 is released!
That should read: I saw that, should it have been 1.0.1 though? mashed the send button mid-correction hehe. On 5/31/06, Ray Krueger [EMAIL PROTECTED] wrote: I saw that, my should it have been 1.0.1 though? On 5/30/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I took the freedom also to tag the source tree and bump the pom versions to 1.1.0-SNAPSHOT On 5/30/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'll take care of that On 5/30/06, Ray Krueger [EMAIL PROTECTED] wrote: Can we get the maven repos updated? Right now mvn compile fails because org.acegisecurity:acegi-security-parent:pom:1.0.0 cannot be downloaded. On 5/30/06, Mark St.Godard [EMAIL PROTECTED] wrote: Hi Ben, The configuration was referencing net.sf... some of the config was moved over to org. however not all. Including the userdetails refactoring. Plus some of the JSPs were also referencing net.sf in page imports. I am running through and testing the app right now, currently failing on a call to getPrincipal from User object... I will fix it up, retest it, run the unit testing and check in the changes. Re: the tutorial app... yeah I noticed that .. very nice... much more concise config. I am usng Spring 2.0 and I am really digging the schema-based config... I am also using MethodSecurityInterceptors using the new Aspect pointcuts. Not sure if we should also include examples of usage using Spring 2.0? I assume we need to wait for it to go final. Uri is on it...Great, I'll keep my eyes posted for acegi:config :) Cheers Mark On 5/30/06, Ben Alex [EMAIL PROTECTED] wrote: Mark St.Godard wrote: Just a note, Ben I will be updating the contacts-tiger sample project, I noticed it was not converted over. I will create an JIRA entry for myself and update this tomorow. I just checked and it looked to me like it was built for 1.0.0. What specifically wasn't converted? Also with Spring 2.0, I noticed that a jira entry was created for namespace handlers, XSD support, etc.. http://opensource.atlassian.com/projects/spring/browse/SEC-271 for those interested. If you have someone to do this fine... otherwise I can take it up... its something that I would really like to get in... and reduce some of the XML verbosity. Uri Boness has volunteered, but I'm unsure whether work has commenced. I am happy for anyone to take a look at it who has sufficient time. As for verbose XML, I'd encourage people to take a look at the new tutorial sample, which is just 148 lines of XML. This includes comments, whitespace and full support for form authentication, remember-me, anonymous and web request authorization. I think that's a pretty good base given the features, but nevertheless it will be even less with SEC-271 improvements. Cheers Ben ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
I'm afraid it's true. It no longer compiles under Spring 1.2.7. Something to log in JIRA for a 1.0.1. On 5/31/06, Ben Munat [EMAIL PROTECTED] wrote: Hi, We upgraded to the 1.0 final jar the other day and things worked fine on our dev build, which uses an InMemoryDao implementation. However, last night we tried to push out a build to the client and the context will no longer start due to a NoClassDefFound in the Acegi code. (FilterBasedLdapUserSearch) I googled for the class -- org/springframework/dao/EmptyResultDataAccessException -- and it's only in Spring 2.0! I hope 1.0 final hasn't presumed that people will switch to Spring 2.0. Is there something I need to change ldap-wise when moving from 1.0 rc2 to 1.0 final? Stacktrace below. Any help greatly appreciated. Heh, this was supposed to be the real production deploy with the client hitting the system hard tomorrow morning (and needing to do some admin setup today). thanks, Ben 2006-05-31 00:34:15,900 INFO org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization started 2006-05-31 00:34:15,902 INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/totaltime] - Loading Spring root WebApplicationContext 2006-05-31 00:34:15,952 INFO org.springframework.core.CollectionFactory - JDK 1.4+ collections available 2006-05-31 00:34:15,962 INFO org.springframework.core.CollectionFactory - Commons Collections 3.x available 2006-05-31 00:34:16,119 ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'userSearch' defined in ServletContext resource [/WEB-INF/config/acegi/fragments/ldapAuthenticationProviderCommon.xml]: Class that bean class [org.acegisecurity.ldap.search.FilterBasedLdapUserSearch] depends on not found; nested exception is java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.springframework.util.ClassUtils.forName(ClassUtils.java:109) at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:65) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:466) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:432) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:347) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.importBeanDefinitionResource(DefaultXmlBeanDefinitionParser.java:374) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:338) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.importBeanDefinitionResource(DefaultXmlBeanDefinitionParser.java:374) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:338) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197)
Re: [Acegisecurity-developer] Acegi Security 1.0.0 is released!
Usually it's bumped to the main next release that will have new features. Not too important though. On 5/31/06, Ray Krueger [EMAIL PROTECTED] wrote: That should read: I saw that, should it have been 1.0.1 though? mashed the send button mid-correction hehe. On 5/31/06, Ray Krueger [EMAIL PROTECTED] wrote: I saw that, my should it have been 1.0.1 though? On 5/30/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I took the freedom also to tag the source tree and bump the pom versions to 1.1.0-SNAPSHOT On 5/30/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'll take care of that On 5/30/06, Ray Krueger [EMAIL PROTECTED] wrote: Can we get the maven repos updated? Right now mvn compile fails because org.acegisecurity:acegi-security-parent:pom:1.0.0 cannot be downloaded. On 5/30/06, Mark St.Godard [EMAIL PROTECTED] wrote: Hi Ben, The configuration was referencing net.sf... some of the config was moved over to org. however not all. Including the userdetails refactoring. Plus some of the JSPs were also referencing net.sf in page imports. I am running through and testing the app right now, currently failing on a call to getPrincipal from User object... I will fix it up, retest it, run the unit testing and check in the changes. Re: the tutorial app... yeah I noticed that .. very nice... much more concise config. I am usng Spring 2.0 and I am really digging the schema-based config... I am also using MethodSecurityInterceptors using the new Aspect pointcuts. Not sure if we should also include examples of usage using Spring 2.0? I assume we need to wait for it to go final. Uri is on it...Great, I'll keep my eyes posted for acegi:config :) Cheers Mark On 5/30/06, Ben Alex [EMAIL PROTECTED] wrote: Mark St.Godard wrote: Just a note, Ben I will be updating the contacts-tiger sample project, I noticed it was not converted over. I will create an JIRA entry for myself and update this tomorow. I just checked and it looked to me like it was built for 1.0.0. What specifically wasn't converted? Also with Spring 2.0, I noticed that a jira entry was created for namespace handlers, XSD support, etc.. http://opensource.atlassian.com/projects/spring/browse/SEC-271 for those interested. If you have someone to do this fine... otherwise I can take it up... its something that I would really like to get in... and reduce some of the XML verbosity. Uri Boness has volunteered, but I'm unsure whether work has commenced. I am happy for anyone to take a look at it who has sufficient time. As for verbose XML, I'd encourage people to take a look at the new tutorial sample, which is just 148 lines of XML. This includes comments, whitespace and full support for form authentication, remember-me, anonymous and web request authorization. I think that's a pretty good base given the features, but nevertheless it will be even less with SEC-271 improvements. Cheers Ben ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
http://opensource.atlassian.com/projects/spring/browse/SEC-288 I made it a blocker for 1.0.1 This means that the 1078 people that have downloaded 1.0.0 to this point cannot use Ldap correct? On 5/31/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'm afraid it's true. It no longer compiles under Spring 1.2.7. Something to log in JIRA for a 1.0.1. On 5/31/06, Ben Munat [EMAIL PROTECTED] wrote: Hi, We upgraded to the 1.0 final jar the other day and things worked fine on our dev build, which uses an InMemoryDao implementation. However, last night we tried to push out a build to the client and the context will no longer start due to a NoClassDefFound in the Acegi code. (FilterBasedLdapUserSearch) I googled for the class -- org/springframework/dao/EmptyResultDataAccessException -- and it's only in Spring 2.0! I hope 1.0 final hasn't presumed that people will switch to Spring 2.0. Is there something I need to change ldap-wise when moving from 1.0 rc2 to 1.0 final? Stacktrace below. Any help greatly appreciated. Heh, this was supposed to be the real production deploy with the client hitting the system hard tomorrow morning (and needing to do some admin setup today). thanks, Ben 2006-05-31 00:34:15,900 INFO org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization started 2006-05-31 00:34:15,902 INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/totaltime] - Loading Spring root WebApplicationContext 2006-05-31 00:34:15,952 INFO org.springframework.core.CollectionFactory - JDK 1.4+ collections available 2006-05-31 00:34:15,962 INFO org.springframework.core.CollectionFactory - Commons Collections 3.x available 2006-05-31 00:34:16,119 ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'userSearch' defined in ServletContext resource [/WEB-INF/config/acegi/fragments/ldapAuthenticationProviderCommon.xml]: Class that bean class [org.acegisecurity.ldap.search.FilterBasedLdapUserSearch] depends on not found; nested exception is java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.springframework.util.ClassUtils.forName(ClassUtils.java:109) at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:65) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:466) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:432) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:347) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.importBeanDefinitionResource(DefaultXmlBeanDefinitionParser.java:374) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:338) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at
[Acegisecurity-developer] maven tests fail
I pulled an update from Subversion, and executed the following... cd core maven test The tests run and then build failed, test failures. One thing I've always wanted to know, and I know Carlos is going to have the quick answer on this... Where is one supposed to go to see what tests failed? Scrolling back through the console looking for FAILED is just lame, and impossible given how many tests we have. The only output is a big pile of XML files, no clue there. ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
Thanks for entering the jira issue for me! I pulled from svn and built my own jar with only two changes and I think it's working now (the client hasn't called to complain yet :-) ). All I did was change two places that use EmptyResultDataAccessException to use the next superclass up, which is IncorrectResultSizeDataAccessException. The two classes that I changed were FilterBasedLdapUserSearch (imports and line 126) and LdapTemplate (imports and line 248). I don't know if this would be a suitable fix for the general population, but it seems pretty self contained. The LdapTemplate throws and the FilterBasedLdapUserSearch catches it and rethrows as a UsernameNotFoundException. I think this change would be fine for general release, but the author of the code should definitely make that call. Thanks for the quick response. Ben PS: I just heard from the client and they're back in business with my patched jar. Ray Krueger wrote: http://opensource.atlassian.com/projects/spring/browse/SEC-288 I made it a blocker for 1.0.1 This means that the 1078 people that have downloaded 1.0.0 to this point cannot use Ldap correct? On 5/31/06, Carlos Sanchez [EMAIL PROTECTED] wrote: I'm afraid it's true. It no longer compiles under Spring 1.2.7. Something to log in JIRA for a 1.0.1. On 5/31/06, Ben Munat [EMAIL PROTECTED] wrote: Hi, We upgraded to the 1.0 final jar the other day and things worked fine on our dev build, which uses an InMemoryDao implementation. However, last night we tried to push out a build to the client and the context will no longer start due to a NoClassDefFound in the Acegi code. (FilterBasedLdapUserSearch) I googled for the class -- org/springframework/dao/EmptyResultDataAccessException -- and it's only in Spring 2.0! I hope 1.0 final hasn't presumed that people will switch to Spring 2.0. Is there something I need to change ldap-wise when moving from 1.0 rc2 to 1.0 final? Stacktrace below. Any help greatly appreciated. Heh, this was supposed to be the real production deploy with the client hitting the system hard tomorrow morning (and needing to do some admin setup today). thanks, Ben 2006-05-31 00:34:15,900 INFO org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization started 2006-05-31 00:34:15,902 INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/totaltime] - Loading Spring root WebApplicationContext 2006-05-31 00:34:15,952 INFO org.springframework.core.CollectionFactory - JDK 1.4+ collections available 2006-05-31 00:34:15,962 INFO org.springframework.core.CollectionFactory - Commons Collections 3.x available 2006-05-31 00:34:16,119 ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'userSearch' defined in ServletContext resource [/WEB-INF/config/acegi/fragments/ldapAuthenticationProviderCommon.xml]: Class that bean class [org.acegisecurity.ldap.search.FilterBasedLdapUserSearch] depends on not found; nested exception is java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException java.lang.NoClassDefFoundError: org/springframework/dao/EmptyResultDataAccessException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.springframework.util.ClassUtils.forName(ClassUtils.java:109) at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:65) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:466) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:432) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:347) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:197) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:295) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.importBeanDefinitionResource(DefaultXmlBeanDefinitionParser.java:374) at
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
That's pretty much the fix that I put in earlier today - the same issue was raised in the forums yesterday http://forum.springframework.org/showthread.php?t=25430 and in Jira as SEC-281. Sorry it wasn't spotted earlier. Perhaps we should change the Spring maven dependency back to 1.2.8 to detect this kind of thing? Luke. Ben Munat wrote: Thanks for entering the jira issue for me! I pulled from svn and built my own jar with only two changes and I think it's working now (the client hasn't called to complain yet :-) ). All I did was change two places that use EmptyResultDataAccessException to use the next superclass up, which is IncorrectResultSizeDataAccessException. The two classes that I changed were FilterBasedLdapUserSearch (imports and line 126) and LdapTemplate (imports and line 248). I don't know if this would be a suitable fix for the general population, but it seems pretty self contained. The LdapTemplate throws and the FilterBasedLdapUserSearch catches it and rethrows as a UsernameNotFoundException. I think this change would be fine for general release, but the author of the code should definitely make that call. Thanks for the quick response. Ben PS: I just heard from the client and they're back in business with my patched jar. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
Sorry it wasn't spotted earlier. Perhaps we should change the Spring maven dependency back to 1.2.8 to detect this kind of thing? That's what i suggested some time ago. In fact for now only 1.2.7 is in ibiblio. ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
Carlos Sanchez wrote: Sorry it wasn't spotted earlier. Perhaps we should change the Spring maven dependency back to 1.2.8 to detect this kind of thing? That's what i suggested some time ago. In fact for now only 1.2.7 is in ibiblio. Wouldn't that subsequently mean that Spring 2.x could surprise us? In more general terms, how do we maximize compatibility testing with all the major versions of Spring, the JDKs, app servers, etc.? Scott ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
In theory Spring is guaranteeing that 2.0 is backwards compatible, so if it works on 1.2.x it'll work on 2.0. In practice we could create a maven 2 profile setting the 2.0 dependencies and setting up continuous integration to build the default (1.2.x) and the profile too (2.x) On 5/31/06, Scott McCrory [EMAIL PROTECTED] wrote: Carlos Sanchez wrote: Sorry it wasn't spotted earlier. Perhaps we should change the Spring maven dependency back to 1.2.8 to detect this kind of thing? That's what i suggested some time ago. In fact for now only 1.2.7 is in ibiblio. Wouldn't that subsequently mean that Spring 2.x could surprise us? In more general terms, how do we maximize compatibility testing with all the major versions of Spring, the JDKs, app servers, etc.? Scott ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Maven 2 repository
Remeber that there's a Maven 2 repository now at http://acegisecurity.sourceforge.net/repository/releases/ I just deployed the 1.0.0, with sources and javadocs. I changed maven deployed jars for the ones in the distribution because they are signed by Ben. It'll be synced to the main maven repository at ibiblio on demand (that means ping me to sync it). -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
