struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Hum (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WW-4873) NotSerializableException - org.apache.struts2.dispatcher.StrutsRequestWrapper
Date Fri, 10 Nov 2017 14:25:00 GMT

    [ https://issues.apache.org/jira/browse/WW-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247556#comment-16247556
] 

Michael Hum commented on WW-4873:
---------------------------------

[~yasser.zamani] Can definitely try that but I'm not 100% sure how that works with websphere
or if we control when it tries to serialize the session. Will have to look into that.

I can try and play with it though. When would be a safe time to try and remove it do you think?
I assume it needs to stay in there for as long as it takes for the interceptor to run across
every potential request using the same session. 

> NotSerializableException - org.apache.struts2.dispatcher.StrutsRequestWrapper
> -----------------------------------------------------------------------------
>
>                 Key: WW-4873
>                 URL: https://issues.apache.org/jira/browse/WW-4873
>             Project: Struts 2
>          Issue Type: Bug
>    Affects Versions: 2.5.13
>            Reporter: Michael Hum
>             Fix For: 2.5.x
>
>
> We are attempting to test session replication on our websphere servers but run into the
given error when websphere tries to serialize the session. 
> {code}
> [10/18/17 10:33:38:094 EDT] 00000335 WASSession    E MTMBuffWrapper getBytes write object
exception. e= java.io.NotSerializableException: org.apache.struts2.dispatcher.StrutsRequestWrapper
> {code}
> It appears the ActionInvocation stores the ActionContext which stores the offending property:
com.opensymphony.xwork2.dispatcher.HttpServletRequest --> StrutsRequestWrapper 
> After a little digging we narrowed it down to our use of the TokenSessionStoreInterceptor
which stores the value in the session and uses it to redirect the failed request to the original
one. Is this intended/expected? Or is there no requirement that the contents in the session
be serializable - in which case we would have to look to our own solution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message