Please keep us posted and let us know how it goes. Regards,
Les On Tue, Sep 15, 2009 at 10:53 AM, Andy Tripp <[email protected]> wrote: > 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... >> > >
