> One thought I have is that perhaps the SecurityManager instance with > which the DelegatingSubject is constructed could be a SecurityManager > proxy? Then you could have control over how that proxy operates - > whether it uses a cached instance or, perhaps upon a reload, the proxy > knows to acquire the new SecurityManager?
Does it need to be that complicated? I've taken a look at the code, but I'm struggling to understand when the subject is created and how long it survives. Is it re-created each request? Or is it bound to a session? If it's recreated each request, why would it be picking up the old security manager? > This sounds like an ideal solution, especially with the latest > Callable/Runnable/RunAs supporting coming in 1.0. These mechanisms > need to retain the SecurityManager instance in use so when transferred > to another thread, that same SM is available on the other thread. If > the SM instance is a proxy, the DelegatingSubject running on the other > threads would be cleanly updated as well. I think this maybe done fairly easily with a Spring ProxyFactoryBean and a hot-swappable target. Alternatively, could the subject just pick up the security manager from the thread context whenever it needs it? Peter
