[anil.saldhana]

1) My SecurityFlushListener is less than a day's work. I tried with the catalina sessionlistener interface and noticed that the callback was never happening. On a deeper look in the tomcat codebase, I realized that there is really a minimal usage of the SessionListener interface. That is when I inferred that the HttpSessionListener inteface has taken precendence over the tomcat SL interface.

2) The issue with http://jira.jboss.com/jira/browse/EJBTHREE-450 is either due to the nonavailability of the SecurityManager in the private namespace of the web component due to the EJB3 impl (very unlikely) or is due to some classloading issues introduced by the clustering framework. I personally emailed the JIRA issue reporter for a reproducible test deployment and not heard back. Doing a JNDI lookup, sometimes the CCE is thrown because of insufficient jars in the classpath. Since the user was using Netbeans, I am not sure.
I have retrofitted the SecurityFlushListener implementation to ignore the nonavailability of a securitymanager in rare scenarios. Now if you ask when will the cache get flushed in this scenario? It will be done as the first step in the next request.

3) My implementation with httpsessionlistener is more than sufficient for the time being. When we do the JSR-196 integration with the containers, we can revisit this issue.

4) The tomcat authenticators have been externalized http://jira.jboss.com/jira/browse/JBAS-2899. This is FYI.

5) Since all the prototyping work starts in JBoss HEAD and not in the 4.0 branch, I do want to tell you that I have already placed an implementation of JSR-196 in HEAD http://jira.jboss.com/jira/browse/JBAS-2525. The work that needs to be done is the container integration with the JASPI layer. Again the implementation work I did was less than a forthnight, so if there are issues, they will prop up during the container integration.

[starksm64]

I would like to see the JSR-196 implementation completed in head with a followup proposal on how to submit this as a replacement for the Realm interface as a generalization of the tomcat authorization SPI.

Regarding the control of the security cache being in jbosssx as a spec issue, the only authentication that even has any notion of a correlation with a session is FORM auth. The jbosssx certainly cannot rely on a web container level cache for many reasons including the fact that its usable without a web container.

[clevelam]

Has a final solution been made for this problem. I'm having a problem getting my custom LoginModule's logout method to call when there is a session timeout.