[
https://issues.apache.org/jira/browse/WICKET-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873861#comment-13873861
]
Martin Grigorov commented on WICKET-5473:
-----------------------------------------
Without a quickstart and steps to reproduce it will be hard to improve it.
Please take some time to prove that it is broken.
> Wicket does not handle non in-memory Httpsessions correctly
> -----------------------------------------------------------
>
> Key: WICKET-5473
> URL: https://issues.apache.org/jira/browse/WICKET-5473
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.12.0
> Reporter: Christoph Läubrich
> Priority: Blocker
>
> There are two issues (related to WICKET-5390):
> 1) The "Wicket-Session" (as well as WebSession) has internal state that is
> not reflected inside equals comparison (e.g. page id counter) since it does
> not override equals. This can leads in de/serialization szenarios to render
> two (Web)Sessions as unequal even if they are in fact the same.
> 2) The "Wicket-Session" object is stored inside the HttpSession object only
> once via setAttribute. This might be persisted. In successive calls the
> internal state is changed (especially the page id counter) but the object is
> not "updated" via setAttribute. This leads to the problem, that the
> HttpSession implementation never knows something has changed and might miss
> to persist the change!
> This leads to duplicate and wrong assigned page ids and confussing errors.
> So the Wicket-(Web)Session should be changed in a way, that:
> a) every internal (non transient) state is used in equals comparisons
> b) each change to any (non transient) internal state causes a setAttribute to
> the underlying storage so it is notified about the change.
> We are hitting this problem with very obscure error messages, so I mark this
> as a blocker since it produces hard to track problems and currently holds us
> down to use Wicket with a persitent (clustered) session model.
> In "standard" configuration you very likely never hit this problem since the
> default PageStore implementation modifies the session so implicitly it gets
> its changes persited. But with alternative PageStore or stateless pages you
> still can hit the problem (and get really confused).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
