You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Bernhard Hirschmann <bh...@web-systeme.de> on 2013/04/17 13:00:32 UTC
NotSerializableException for ShiroHttpServletRequest
I'm having problems with the activeSessionsCache, for which I'm using
WebSphere's DistributedMap.
Seems like the ShiroHttpServletRequest doesn't implement
java.io.Serializable:
[17.04.13 12:37:18:970 CEST] 00000007 CacheEntry E DYNA0052E: The
cached object can not be replicated or saved to disk. CacheID:
4f68f164-8d2a-493b-aa98-036f243600a1 ClassName:
org.apache.shiro.session.mgt.SimpleSession Type: cache-value Exception:
java.io.NotSerializableException:
org.apache.shiro.web.servlet.ShiroHttpServletRequest
I will try to add the Serializable interface, but I'm not sure beeing on the
right path. Any comments about this?
B.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/NotSerializableException-for-ShiroHttpServletRequest-tp7578607.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Les Hazlewood <lh...@apache.org>.
" 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 <lh...@apache.org> 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
> <bh...@web-systeme.de> 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.
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Les Hazlewood <lh...@apache.org>.
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
<bh...@web-systeme.de> 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.
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Bernhard Hirschmann <bh...@web-systeme.de>.
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.
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Les Hazlewood <lh...@apache.org>.
P.S. The previous description mostly applies to native session management.
For those using servlet-container based sessions (Shiro's default
configuration), the same concepts apply down to the SessionManager. From
that point on, the ServletContainerSessionManager implementation differs
greatly from the native SessionManagers since it will delegate everything
to the Servlet Container for session management.
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Thu, Apr 18, 2013 at 9:43 AM, Les Hazlewood <lh...@apache.org>wrote:
> 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 <
> bh.shiro@web-systeme.de> 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.
>>
>
>
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Les Hazlewood <lh...@apache.org>.
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 <
bh.shiro@web-systeme.de> 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.
>
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Bernhard Hirschmann <bh...@web-systeme.de>.
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.
Re: NotSerializableException for ShiroHttpServletRequest
Posted by Les Hazlewood <lh...@apache.org>.
ServletRequests are not serializable on purpose - they represent a
particular request execution at a particular moment in time. There
isn't any reason I can think of to serialize and then deserialize them
out of memory.
I suspect something you might be saving in a session attribute has a
direct reference to the request. You should make that property
transient if so.
HTH!
Best,
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Wed, Apr 17, 2013 at 4:00 AM, Bernhard Hirschmann
<bh...@web-systeme.de> wrote:
> I'm having problems with the activeSessionsCache, for which I'm using
> WebSphere's DistributedMap.
> Seems like the ShiroHttpServletRequest doesn't implement
> java.io.Serializable:
>
> [17.04.13 12:37:18:970 CEST] 00000007 CacheEntry E DYNA0052E: The
> cached object can not be replicated or saved to disk. CacheID:
> 4f68f164-8d2a-493b-aa98-036f243600a1 ClassName:
> org.apache.shiro.session.mgt.SimpleSession Type: cache-value Exception:
> java.io.NotSerializableException:
> org.apache.shiro.web.servlet.ShiroHttpServletRequest
>
> I will try to add the Serializable interface, but I'm not sure beeing on the
> right path. Any comments about this?
>
> B.
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/NotSerializableException-for-ShiroHttpServletRequest-tp7578607.html
> Sent from the Shiro User mailing list archive at Nabble.com.