Bug in security cache

I've found (I think) a reasonably serious problem with JaasSecurityManager in JBoss 4.0.4.GA around caching. It doesn't happen very often but it can result in a logged-out Subject on the stack.

The root of the problem appears to be JaasSecurityManager.authenticate(), where it logs on first via defaultLogin() which results in a new SubjectContext on the stack. Authenticate() makes a subsequent call to updateCache(), which replaces the old cache entry with the new Subject, which in turn causes the LoginContext associated with the old cache entry to log out. This results in ClientLoginModule.logout() to be called, which logs out the expired Subject (by removing the Principal). It then pops the stack, which unfortunately does not result in the expired and logged-out Subject to get removed, but the recently-added Subject from defaultLogin().

This particular chain of events I would guess is mostly harmless, except in a particular situation that I find myself in:

1/ The security cache for the principal must timeout out before the web request is processed - thus we at the beginning of the request we get a Subject in the cache that has a LoginContext that is associated with a "live" Subject - it is on the stack.
2/ The security cache lookup must fail in a subsequent call within the same request where credentials do not match. Thus the getCacheInfo() call in isValid() succeeds, but validateCache() then returns false, which triggers the call to authenticate(). This happens for me when the credentials get mixed up between Strings and char[]. I've made another post on this point, but essentially ClientLoginModule generates char[] credentials, while FormAuthenticator generates Strings.

The result of this unlikely combination of events is that a Subject on the stack gets logged-out so all its Principals get removed, but it remains on the stack, causing the application to fail when trying to work out who is logged in.

I would love to suggest here an obvious and simple solution, but I can't see one at this stage.

I have checked the head of the trunk of SVN and the relevants bits of code don't appear to have changed.