Re: Checking obscure serialization bugs during development

[mscoon <ms...@gmail.com>]

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
PageStoreManager$SessionEntry object, and nullify it's private sessionCache
attribute. So this results is some ugly code accessing wicket internals but
it seems to work, and since it's only for testing, it's okay.

Thanks for the help,
Martin.

On Wed, Jan 14, 2015 at 10:32 AM, Martin Grigorov <mg...@apache.org>
wrote:

> 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:
> Session().get().removeAttribute("wicket:persistentPageManagerData - " +
> Application.get().getName())
> This way Wicket will always load the page from the second/third level
> stores (i.e. its serialized version).
>
> See http://wicket.apache.org/guide/guide/internals.html#pagestoring for
> some more details.
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Jan 13, 2015 at 6:30 PM, mscoon <ms...@gmail.com> wrote:
>
> > 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 often go unnoticed during development since usually the active
> > page is kept in memory.
> >
> > So I was wondering if there is a way to force wicket during development
> to
> > always serialize pages and never keep any pages in memory in order to
> make
> > such bugs more apparent to the developer.
> >
> > Thanks in advance
> > Marios
> >
>

Re: Checking obscure serialization bugs during development

[Martin Grigorov <mg...@apache.org>]

Welcome,
Marios!
:-)
On May 3, 2015 7:04 PM, "mscoon" <ms...@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 7:01 PM, mscoon <ms...@gmail.com> wrote:
>
> > 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
> > PageStoreManager$SessionEntry object, and nullify it's private
> sessionCache
> > attribute. So this results is some ugly code accessing wicket internals
> but
> > it seems to work, and since it's only for testing, it's okay.
> >
> > Thanks for the help,
> > Martin.
> >
> > On Wed, Jan 14, 2015 at 10:32 AM, Martin Grigorov <mg...@apache.org>
> > wrote:
> >
> >> 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:
> >> Session().get().removeAttribute("wicket:persistentPageManagerData - " +
> >> Application.get().getName())
> >> This way Wicket will always load the page from the second/third level
> >> stores (i.e. its serialized version).
> >>
> >> See http://wicket.apache.org/guide/guide/internals.html#pagestoring for
> >> some more details.
> >>
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Tue, Jan 13, 2015 at 6:30 PM, mscoon <ms...@gmail.com> wrote:
> >>
> >> > 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 often go unnoticed during development since usually the
> >> active
> >> > page is kept in memory.
> >> >
> >> > So I was wondering if there is a way to force wicket during
> development
> >> to
> >> > always serialize pages and never keep any pages in memory in order to
> >> make
> >> > such bugs more apparent to the developer.
> >> >
> >> > Thanks in advance
> >> > Marios
> >> >
> >>
> >
> >
>

Re: Checking obscure serialization bugs during development

[mscoon <ms...@gmail.com>]

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 <ms...@gmail.com> wrote:

> 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
> PageStoreManager$SessionEntry object, and nullify it's private sessionCache
> attribute. So this results is some ugly code accessing wicket internals but
> it seems to work, and since it's only for testing, it's okay.
>
> Thanks for the help,
> Martin.
>
> On Wed, Jan 14, 2015 at 10:32 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> 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:
>> Session().get().removeAttribute("wicket:persistentPageManagerData - " +
>> Application.get().getName())
>> This way Wicket will always load the page from the second/third level
>> stores (i.e. its serialized version).
>>
>> See http://wicket.apache.org/guide/guide/internals.html#pagestoring for
>> some more details.
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Jan 13, 2015 at 6:30 PM, mscoon <ms...@gmail.com> wrote:
>>
>> > 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 often go unnoticed during development since usually the
>> active
>> > page is kept in memory.
>> >
>> > So I was wondering if there is a way to force wicket during development
>> to
>> > always serialize pages and never keep any pages in memory in order to
>> make
>> > such bugs more apparent to the developer.
>> >
>> > Thanks in advance
>> > Marios
>> >
>>
>
>