Thanks, Les, I'll take it from here. Andy
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Les Hazlewood > Sent: Tuesday, September 15, 2009 10:23 AM > To: [email protected] > Subject: Re: need help plugging in my own session cache > > Hi Andrew, > > I've verified that the Cache is being called properly in the debugger > and that authorization data is being cached properly. > > Here is my test configuration (the trunk/samples/web web.xml, slightly > modified). Remember, the order in which the configuration elements > are defined matters - they translate to method calls, which internally > alter state. There is an ordering bug - see the config comments > below: > > <filter> > <filter-name>ShiroFilter</filter-name> > <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter- > class> > <init-param> > <param-name>config</param-name> > <param-value> > [main] > securityManager.sessionMode = native > > # Ordering bug - these 2 lines _must_ be defined before > # defining the CacheManager and setting it on the > securityManager (below): > sessionDAO = > org.apache.shiro.session.mgt.eis.MemorySessionDAO > securityManager.sessionDAO = $sessionDAO > > cacheManager = test.TestCacheManager > securityManager.cacheManager = $cacheManager > > demoRealm = org.apache.shiro.realm.text.PropertiesRealm > securityManager.realm = $demoRealm > > [filters] > authc.loginUrl = /login.jsp > > [urls] > # The /login.jsp is not restricted to authenticated > users (otherwise no one could log in!), but > # the 'authc' filter must still be specified for it so > it can process that url's > # login submissions. It is 'smart' enough to allow > those requests through as specified by the > # shiro.loginUrl above. > /login.jsp = authc > > /account/** = authc > /remoting/** = authc, roles[b2bClient], > perms["remote:invoke:lan,wan"] > </param-value> > </init-param> > </filter> > > And here is my test.TestCacheManager implementation: > > public class TestCacheManager implements CacheManager { > > Map<String, Cache> caches = new ConcurrentHashMap<String, Cache>(); > > public Cache getCache(String name) throws CacheException { > if (name == null) { > throw new NullPointerException("name"); > } > > Cache cache = caches.get(name); > if (cache == null) { > //MapCache with ConcurrentHashMap for testing only > //this would cause OutOfMemoryExceptions in a real app since > it > //would never proactively release instances. Use a > SoftHashMap in production > //environments, or better yet, a CacheManager > implementation supported > //by an enterprise Cache product (TerraCotta, Coherence, > GigaSpaces, etc). > cache = new MapCache(name, new ConcurrentHashMap()); > caches.put(name, cache); > } > > return cache; > } > } > > Regards, > > Les > > On Tue, Sep 15, 2009 at 9:44 AM, Les Hazlewood <[email protected]> > wrote: > > On Mon, Sep 14, 2009 at 4:15 PM, Andy Tripp <[email protected]> > wrote: > > > >> Cache's get() and put() methods are never called, and I can try > tracking > >> down the problem, but I can't figure out what class should be making > >> these > >> calls. > > > > These would be done by the Realm instance, via the superclass > > AuthorizingRealm implementation - specifically in the > > 'getAuthorizationInfo' method. This method checks the cache, and if > > not found in the cache, then delegates to the 'doGetAuthorizationInfo' > > method which is implemented by subclasses. > > > > I hope that helps - I'll keep debugging from my end... > >
