Insights on the Wicket page id mechanism

Question

I've read a lot of documentation and code over the last couple of weeks, but for some special questions I'm still not able to "connect the dots" of how the page id mechanism works. Let me sketch the situation.

In my Wicket application there are two pages running in parallel in the same session (two-monitor-setup, I'll refer to them as the "left" and the "right" page).

What I do understand is the following:

• Wicket's page ids are session unique. This way, e.g. the left page, that is displayed first, gets id ?0, the right page gets id ?1.
  • Theory: Wicket only supports one "current" page id, which is the highest id used in the session. This way, even as I did not manipulate a page yet, id ?0 of the left page is technically outdated already and refreshing it would yield id ?2. Is this a correct assumption?
• Manipulating pages in a way that affects the Wicket backend increases this id - again, session unique. If I first manipulate the right page, it gets id ?2. If I now manipulate the left page, it gets id ?3 - in practice it sometimes even gets id ?4, not completely sure what causes this, but thats not an issue.
• Wicket's re-rendering algorithm includes serialization and deserialization of pages.
  • Theory: In case of refreshing a page with an "outdated" id (see theory above), deserialization is the way to go (at least thats what my debugging attempts told me, but that deep inside in the Wicket code it's not particularly easy to see whats going on and why). Is that a correct assumption - can I only move on from id ?0 to id ?3 by deserializing whats saved inside the page storage under id 0?

Now here comes the tricky part - our Wicket application is embedded in an OSGi environment and the components that are displayed on the page are actually implemented in different bundles. Therefore, whenever this just mentioned deserializing occured, the outcome was a nice deserialization exception because Wicket could not access the component's class anymore. Using wicketstuff-osgi and dependency injection solved this problem.

As long as I work only with one window, everything is perfectly fine. The page id of this pages increases on occasion, but wicket is able to handle everything.

When there are two pages, the following happens:

1. Open the left page.
2. Manipulate the left page.
3. Open the right page.
4. Manipulate the right page.
5. Manipulate the left page.

Apparently now wicket discovers that the page id of the left page has to "jump" and in process of this id jumping the old page with id 0 needs to be deserialized.

My questions are now the following: Are my assumptions of how the page id mechanism works correct? Is this deserialization neccessary or avoidable? Does it only happen because of some misconfiguration (I can provide further configuration details if you have specific questions)? And why is that the case? Like I said, I tried digging into that code, but I hope for some clarification from someone who's more familiar with it.

Answer 1

Here's a link to the relevant section of the Wicket guide:

http://wicket.apache.org/guide/guide/versioningCaching.html

It explains in some detail page versioning and the different parts involved.

If you cannot afford to have pages serialized, you can use the HttpSessionDataStore described here which keeps pages in the http session. Have a look at this email thread from the mailing list also if you're going that route as it contains important gotchas to avoid.