[
https://issues.apache.org/struts/browse/WW-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45109#action_45109
]
Sitaram Reddy commented on WW-2902:
-----------------------------------
This issue should be reopened. The above resolution fixes this specific issue
but does not address the root cause. I notice
ExecuteAndWaitInterceptor.doIntercept(...) also uses this object ( =
ActionContext.getContext().getSession() ) to synchronize a block of code. There
may be others still doing the same.
It seems to me the root cause of this problem is the assumption that
ActionContext.getContext().getSession() is an object of SESSION scope. That
would be a natural assumption. After all, it is a substitute for the
HttpSession object which has SESSION scope. That a 'getSession()' method would
return a 'Session' kind of an object that would be of SESSION scope makes
sense. Developers have implicitly assumed this, and have often times used the
variabale name 'session' for this object. And, apparently, they have been using
this object to synchronize threads across a SESSION. It would involve a lot
more work, but I believe the correct fix for this issue is to have
ActionContext.getContext().getSession() return an object that has SESSION scope.
> Session token usage error: java.lang.IllegalStateException: Context has not
> been prepared for next connection
> -------------------------------------------------------------------------------------------------------------
>
> Key: WW-2902
> URL: https://issues.apache.org/struts/browse/WW-2902
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.1.2
> Reporter: Sitaram Reddy
> Fix For: 2.1.3
>
>
> I have looked into the source code and found the reason. In
> TokenInterceptor.doIntercept(...), there is this code:
> Map session = ActionContext.getContext().getSession();
> synchronized (session) {
> if (!TokenHelper.validToken()) {
> return handleInvalidToken(invocation);
> }
> return handleValidToken(invocation);
> }
> This block is essentially not synchronized! I found that the session Map is
> not a unique object across requests within an user session - in contrast with
> the HttpSession object provided by the Servlet API. Perhaps that should be
> considered the real bug?
> A previous bug WW-1786 also points out that the above block is not
> synchronized - that fix would be redundant once this issue is resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
