Yes, thanks Martin for reporting this. I believe your marking the Subject injection points in the code as transient makes sense and is more 'correct' based on Shiro's current implementation. Subject instances can come and go in an application depending on who is currently executing the backing thread. This sounds like a strong reflection of the word transient to me:
For example, if you were to serialize a component with a referenced Subject and then reconstitute that component later on, does it make sense for that exact subject instance (with its identity and session state) to pick up from where it left off? I would assume not, but maybe it does - I'm not sure. Such a scenario is currently undefined for Shiro. I think this issue surfaces from a thin line in interpretation: Subject as a term in general means 'the currently executing end-user'. But the actual runtime Subject _instance reference_ (memory pointer) means a very specific executing end-user at that exact moment in time. Now, perhaps the best way to solve this is by having SecurityUtils.getSubject() return a serializable proxy: you can retain the returned Subject instance and serialize it. But 'under the hood' it delegates to the 'real' logic to look up the instance from the thread at runtime. That way the proxy serializes safely, but method calls on it will always reflect the underlying runtime reference. We could do this, and I think it would retain backwards-compatible behavior, but it creates one question: When deserializing the Subject proxy, and that proxy looks for a Subject on the thread at runtime, but one does not exist (due to erroneous configuration, or unexpected environment, etc), we throw something akin to an IllegalStateException? Is this more desirable than asking the developer to think the runtime reference's transient nature? If anyone has any thoughts on this, please contribute. Cheers, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
