It looks like that all starts from this test...

Running 
org.springframework.security.providers.ldap.authenticator.PasswordComparisonAuthenticatorTests

On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> This type of stuff seems to be where it takes the longest...
>
> 2007-11-04 12:39:38,062 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=******,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
> 2007-11-04 12:39:53,203 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=******,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
> 2007-11-04 12:40:08,218 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=******,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
> 2007-11-04 12:40:23,218 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=******,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
>
>
>
> On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > Maven version: 2.0.7
> > Java version: 1.6.0_01
> > OS name: "windows xp" version: "5.1" arch: "x86"
> >
> > Yeah, the console scrolled way too far back for me to see what failed.
> > That was just the snippet of the end of the log I showed.
> >
> > I'm running it again with a fresh batch of code, and running it from
> > the project root.
> >
> > On 11/4/07, Luke Taylor <[EMAIL PROTECTED]> wrote:
> > > What tests are failing? And what platform are you running on, JVM, Maven
> > > version etc?
> > >
> > > The stuff about ehcache is something to do with the shutdown hooks in
> > > all the application contexts being executed when the VM exits so that's
> > > not the problem, though we should be aiming to make sure that existing
> > > tests call close() on any created app contexts to avoid this.
> > >
> > > Both my automated build and the ones on build.springframework.org seem
> > > to be running without any problems and I just built on my desktop
> > > machine (1min 29s for a "mvn clean test"):
> > >
> > > Maven version: 2.0.7
> > > Java version: 1.5.0_07
> > > OS name: "mac os x" version: "10.4.10" arch: "i386"
> > >
> > >
> > >
> > >
> > > Ray Krueger wrote:
> > > > I just pulled the latest code from Trunk this morning. I ran the unit
> > > > tests in ./core and had the following result...
> > > >
> > > > 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting
> > > > down with the CacheManager st
> > > > ill active. Calling shutdown.
> > > > Exception in thread "Thread-77" java.lang.IllegalStateException: The
> > > > aclCache Cache is not alive.
> > > >         at net.sf.ehcache.Cache.checkStatus(Cache.java:1201)
> > > >         at net.sf.ehcache.Cache.dispose(Cache.java:1081)
> > > >         at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702)
> > > >         at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505)
> > > > [INFO] 
> > > > ------------------------------------------------------------------------
> > > > [ERROR] BUILD FAILURE
> > > > [INFO] 
> > > > ------------------------------------------------------------------------
> > > > [INFO] There are test failures.
> > > > [INFO] 
> > > > ------------------------------------------------------------------------
> > > > [INFO] For more information, run Maven with the -e switch
> > > > [INFO] 
> > > > ------------------------------------------------------------------------
> > > > [INFO] Total time: 30 minutes 11 seconds
> > > > [INFO] Finished at: Sat Nov 03 21:11:26 CDT 2007
> > > > [INFO] Final Memory: 15M/27M
> > > > [INFO] 
> > > > ------------------------------------------------------------------------
> > > >
> > > >
> > > > Not cool, I'm not sure what's going on, but it appeared to be spending
> > > > all it's time in ldap tests.
> > > >
> > >
> > >
> > > --
> > >  Luke Taylor.                      Monkey Machine Ltd.
> > >  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> > >
> > >
> > > -------------------------------------------------------------------------
> > > 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
> > >
> >
>

-------------------------------------------------------------------------
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

Reply via email to