Wicket: Best practice for deployment to avoid ClassNotFoundException

Question

I'm new to wicket and just recently started to use it for a new web app for one of our projects. Today I came across a similar issue like described in WICKET-4785, a ClassNotFoundException during deserialization of a page. The interesting part about this in my mind is, that the mentioned missing class was missing for a good reason: I simply refactored a bit and renamed the class, redeployed and restarted my Tomcat. This looks like a normal use case to me, but is something I didn't thought of when I've read through the docs because.

My deployment is very simple: I check out a SVN working copy with a pre-configured tag containing the whole application once and afterwards just need to merge/update and stop/start the web server/app.

How is deployment supposed to work in Wicket after I have refactored or otherwise changed my classes regarding cached and serialized pages? Is there anything I need to tell wicket to clear its caches on each deployment or ignore those or whatever? Am I forced to not delete once deployed classes for a fair period of time? That would be a litte nightmare... Or is there any other issue I ran into I should have avoided?

Obviously others do deploy their Wicket apps as well, so I hope you have some input on how to avoid the problem I've ran into. Thanks!

The important parts of the stacktrace:

java.lang.ClassNotFoundException: de.am_soft.util.frontend.wicket.markup.link.LogoutLink
     at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
     at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Unknown Source)
     at org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108)
     at org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream.resolveClass(JavaSerializer.java:218)
     at java.io.ObjectInputStream.[...]
     at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:122)
     at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:396)
     at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:135)
     at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:203)
     at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:360)
     at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:107)

I posted this question on the Wicket users list as well, but didn't get much response yet, although I thought this is an easy question...

Answer 1

Wicket is a stateful web framework that stores page instances to facilitate a tight user interaction between browser and server. This means serializing the component hierarchy of each page so a user can interact with the component hierarchy, modify it (replacing panels for example) and expect the client and server to be in sync.

When you refactor your classes such as renaming a link class, the deserializer can't find that class and you get this ClassNotFoundException. To mitigate this you:

a. need to start a new session in your browser so that Wicket doesn't tie your browser to the server state with the old classes (throw the jsessionid cookie away), or

b. construct a new page instance inside your session (remove the ?0 or ?1231 parameter in the URL in your browser), or

c. clear all session data on the server