The interface would be handy in many occasions. Although I say the default implementation needs to throw a runtime exception if a given count isn't implemented in that environment. If we make it easy for users to configure their own implementations (and contribute back) we'd likely only need to implement a default SessionListener for servlet environments. Probably useful to model the interface after some existing implementation, such as Webshere's (http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rprf_datacounter6.html) though there might be better ones.
Kalle On Wed, Feb 3, 2010 at 12:45 PM, Les Hazlewood <[email protected]> wrote: > Bump. I was thinking about working on this today, but wanted to get > some feedback before I touch anything. Any ideas? > > On Thu, Jan 21, 2010 at 5:01 PM, Les Hazlewood <[email protected]> wrote: >> Hi devs (et. al), >> >> In trying to address this issue: >> >> https://issues.apache.org/jira/browse/SHIRO-117 >> >> I've realized that just having the QueryableSessionDAO wouldnt' be as >> useful as it could be. The SessionManager interface should probably >> reflect this added functionality too. So maybe we should probably >> have methods like: >> >> SessionManager.getActiveSessionCount() : long >> etc. >> >> where these methods return -1 if that functionality isn't supported by >> the underlying SessionDAO. >> >> This is the cleanest thing I can think of - the SessionManager >> interface must remain constant regardless of what the SessionDAO can >> support. Some cache APIs have similar methods because they can't >> guarantee that the underlying implementations support statistics. >> >> Any thoughts? >> >> - Les >> >
