Hi Jack, By default, Shiro web apps use the ServletContainerSessionManager which uses the Servlet Container's session mechanisms using the standard HttpServletRequest.getSession() API.
If you want to have finer control over the session experience in a web app, you'll want to enable Shiro's 'native' sessions. You can do this by explicitly setting 1) the SecurityManager's 'sessionMode' property to 'native' or 2) explicitly configure the DefaultWebSessionManager instance. 1. [main] # no need to call securityManager = DefaultWebSecurityManager - this is done by default in web environments securityManager.sessionMode = native sessionDAO = com.some.SessionDAOImplementation securityManager.sessionManager.sessionDAO = $sessionDAO 2. [main] sessionDAO = com.some.SessionDAOImplementation sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager sessionManager.sessionDAO = $sessionDAO securityManager.sessionManager = $sessionManager cacheManager = org.foo.SomeCacheManager securityManager.cacheManager = $cacheManager In #1, calling securityManager.sessionMode = native is just a 'shortcut' for instantiating the DefaultWebSessionManager and injecting it into the securityManager instance. This can lead to problems if this is called out of order. Because of this, I prefer approach #2, which is explicit and defines the object graph in a well-known, expected order. Also, notice that the cacheManager is configured last so it can propagate to all objects that implement the 'CacheManagerAware' interface. Ensure your SessionDAO implementation implements this interface (or alternatively extend the CachingSessionDAO class) to ensure your DAO can perform caching. Does this help? Cheers, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
