Hi, I guess you already know that Wicket serializes the pages at the end of the request cycle. After deserialization the object id is no more the same as the one before serialization. You should not rely on "same JVM instance".
Check Wicket-Examples demo for ModalWindow. It uses PageReference to get access to the page instance that opened the ModalWindow. On Mon, May 27, 2013 at 11:16 AM, Rafael Barrera Oro <[email protected]>wrote: > Hello! > > I have such a weird problem i dont think i will be able to explain it in > one shot, i'll try anyway. > > The thing is have a page (a class that descends from WebPage) that uses a > popup (using a class that descends from ModalWindow), and the popup itself > shows a new popup (again, by using a ModalWindow descendant class). The > (very weird) problem is that after the second popup is shown (the popup > within the popup, that is) the objects the execution path seems to return > to are different! > > The flow is something like the following: > > page (java object id A) opens popup -> popup (java object id B) opens popup > -> popup asks for yes or no (either way its closed) > > by debbuging i see that after this, the java object id of the first popup > is not B anymore! > > The thing that i find most weird is that this only happens if the second > popup is opened, could the opening or closing of the popup cause something > like this? > > I know it sounds weird, it does not make any sense and its very much more > likely to be a mistake unseen by me than a bug in the JDK :P but i wanted > to ask anyway, in case someone has seen or heard about something that > resembles this (even if it does very vaguely) > > Thanks in advance! > Rafael >
