Critical Description
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).
Attachments
Attachments
Issue Links
- is broken by
-
WICKET-5380 Wicket rebinds the SessionEntry session attribute and this causes problems in Glassfish
-
- Resolved
-
- is related to
-
WICKET-2782 Don't increment the Session.pageIdCounter for stateless pages
-
- Reopened
-
- supercedes
-
-
- Resolved
-