Re: Checking obscure serialization bugs during development

2015-05-03 Thread mscoon
Hi, it turns out that removing the session attribute as in Session().get(). removeAttribute(wicket:persistentPageManagerData - + Application.get().getName()) does not work because the result is that no pages are ever retrieved. Instead you need to get the attribute, which is a

Re: Checking obscure serialization bugs during development

2015-05-03 Thread mscoon
Heh, and a wrong carriage-return in the end makes me look like I'm trying to assume Martin's identity :) So anyway, thanks for the help Martin, as always you give very good guidance! Marios On Sun, May 3, 2015 at 7:01 PM, mscoon msc...@gmail.com wrote: Hi, it turns out that removing the

Re: Checking obscure serialization bugs during development

2015-05-03 Thread Martin Grigorov
Welcome, Marios! :-) On May 3, 2015 7:04 PM, mscoon msc...@gmail.com wrote: Heh, and a wrong carriage-return in the end makes me look like I'm trying to assume Martin's identity :) So anyway, thanks for the help Martin, as always you give very good guidance! Marios On Sun, May 3, 2015 at

Re: Checking obscure serialization bugs during development

2015-01-14 Thread Martin Grigorov
Hi, There is no setting to tell Wicket to not store the page(s) used in the last request cycle in the memory (http session). But you can workaround this by null-ifying the session attribute in IRequestCycleListener#onBeginRequest() for example. You need something like:

Checking obscure serialization bugs during development

2015-01-13 Thread mscoon
Hi all, There are some application (not wicket!) bugs that occur only when wicket serializes a page, while the same code works if the page is kept in memory during subsequent requests. For instance a == comparison may fail if either side of the expression is serialized/deserialized. These bugs