Ah yes, this makes much more sense to me now - thanks for clarifying. 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?
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. Would this be an acceptable solution? Or does anything else come to mind? - Les On Thu, Sep 3, 2009 at 10:31 AM, Peter Ledbrook<[email protected]> wrote: >> What do you mean exactly by modifying a realm? I would guess that you >> mean changing state/attributes on an existing Realm instance. Is this >> correct? Or are you talking about adding or removing realm instances >> on the SecurityManager at runtime? > > I mean changing the code in the realm, for example by adding a print > statement, or modifying the behaviour of isPermitted(). > >> The application SecurityManager instance shouldn't need to be swapped >> at runtime. Any changes to its configuration should be dynamically >> applied, IMO. But this might be a different discussion - I don't see >> how modifying an existing realm instance's state would have any effect >> on the security manager. > > Because the realm's class changes, Spring has to update everything > that ultimately references it. In other words, all beans that directly > or indirectly depend on the realm have to be reloaded, security > manager included. > > Hope that clears things up, > > Peter >
