" and (potentially)" other non-serializable things. -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Sat, Apr 20, 2013 at 12:15 PM, Les Hazlewood <[email protected]> wrote: > 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.
