Les and Peter,
Making the following change fixed the problem. Subsequent requests are now
accessing the cache.
"mgr.realms += beans.collect { applicationContext.getBean(it) }"
Thanks for all your help on this issue. I really appreciate it.
Best regards,
Thomas
-----Original Message-----
From: Peter Ledbrook [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 12:38 AM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
> DefaultWebSecurityManager securityManager = new
DefaultWebSecurityManager();
> securityManager.init(); // <-- the securityManager has a default
> EhCacheCacheManager if ehcache is in the classpath, but your Realm
> doesn't have it yet
>
> securityManager.setRealm( myRealm );
> //now 'myRealm' will have the cacheManager instance and its
> AuthorizationInfo cache will be created.
Ah, I think I can see what the problem is. The normal realms
configured by the plugin are added in the bean definition, so they
will be initialised during "securityManager.init()". However, I add
native JSecurity realms once the security manager has been
instantiated:
100 // Finally add the remaining beans to the security manager.
101 log.info "Registering native realms: $beans"
102 def mgr = applicationContext.getBean('jsecSecurityManager')
103 mgr.realms.addAll(beans.collect {
applicationContext.getBean(it) })
Since I'm adding the beans to the existing realms collection, the
cache manager stuff is not triggered for those realms. This is already
a hack, since plugins can't see bean definitions from
"resources.groovy" or "resources.xml". I could just call "mgr.realms
+= beans.collect { applicationContext.getBean(it) }".
Cheers,
Peter
--
Software Engineer
G2One, Inc.
http://www.g2one.com/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
