A ShiroHttpSession instance is only used during a request and it's really just a javax.servlet.http.HttpSession implementation that wraps the current Subject's org.apache.shiro.session.Session instance.
At runtime, that org.apache.shiro.session.Session instance is itself a proxy that delegates most calls to the SessionManager. The SessionManager in turn manages the application's overall set of SimpleSession instances. SimpleSession instances are the actual datastore entities that are persistent and clusterable (they're Serializable POJOs that have their own properties as well as an attributes map). This is sort of hinted at in the Architecture documentation here: http://shiro.apache.org/architecture.html It's not clear from that page what is going on exactly with sessions, but hopefully it can give you a visual reference to support the above description of wrappers/proxies. HTH! Best, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Thu, Apr 18, 2013 at 5:50 AM, Bernhard Hirschmann < [email protected]> wrote: > Hello Les, > > thanks for your help -- thats seems to be a good thought. > > Seems like the class ShiroHttpSession has a field currentRequest of the > type > HttpServletRequest. If the session is beeing serialized for the sync > between > the cluster members, then this might cause the problem. > > But if this really is the problematic spot, why don't other developers have > this problem? Still confusing for me.. > > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/NotSerializableException-for-ShiroHttpServletRequest-tp7578607p7578617.html > Sent from the Shiro User mailing list archive at Nabble.com. >
