I'm not sure it would be worth all the effort it would take to make it serializable.
The ShiroHttpServletRequest has an internal reference to the ServletContext and (potentially). You wouldn't want to serialize the entire ServletContext, so you'd have to make it transient and then find a way to reacquire it upon deserialization. But other things in Shiro assume a request-only scope and so you'd have to address them as well. But I think this approach is a red herring: Storing a request *in* a session is a poor design approach IMO: requests are request scoped (only), and sessions are multi-request scoped by definition. Trying to store a request-only-scoped object into an object that must exist across requests, and is free to be serialized by the servlet container for clustering purposes, is a bad idea. By their own documentation, "A rollover scope is essentially a map stored within session scope". If that's the case, why don't they implement it that way? That's the only safe way to guarantee their feature won't break session clustering. This isn't a Shiro-specific problem by the way - if *any* servlet container was used and clustering was turned on, the Struts' implementation would break when the Servlet container decided to serialize a session. This is an indicator to me that they need to refactor their code (IMO). HTH, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Fri, Apr 19, 2013 at 5:33 AM, Bernhard Hirschmann <[email protected]> wrote: > Thanks for the directions, Les. You're right, the ShiroHttpSession is not the > problem, since SimpleSession is the actual object type for keeping all the > session data stored. And both classes have no relationship to each other. > Firstly I thought SimpleSession was a Shiro class, implementing > ShiroHttpSession, or similar. That was wrong. > > I think I found the reason now. The project is using Struts 1.3.10 with an > early version of RolloverScope > (http://wiki.apache.org/struts/RolloverScope). This keeps the scope infos in > the session, including a reference to the request, which is of the type > org.apache.shiro.web.servlet.ShiroHttpServletRequest. > > Now I'm, looking for the best way to get around this trouble. Either > preventing the request object beeing kept in the session (which might have > critical side effects), or to make the ShiroHttpServletRequest serializable > for this purpose. > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/NotSerializableException-for-ShiroHttpServletRequest-tp7578607p7578631.html > Sent from the Shiro User mailing list archive at Nabble.com.
