Are you using our modal window implementation or your own?
Wicket implementation. BTW, I have another modal window that doesn't create problem. I'll later post the code, when I'm able to cut it down.
3. I have still some confusion about serialization of things in sessions. I've always got some objects that are not serializable and caused tons of exceptions in log files, but no harm other than it. I'm now wondering whether they can trigger one of the above problems, and anyway before going into production I'd like to face with this issue in a definitive fashion. I know about the possibility of using detachable objects, nevertheless I need first to understand why this serialization thing can't be disabled - after all I've got no need for clustering in near future (and if I should do it, I'd probably go with Terracotta). Also, in version 1.2 I once saw that there was a UserSession (?) method that looked like it was useful for disabling serialization, and I had a mental note about using it, but it looks like it disappeared in 1.3.0. Hints?Serialization has always been needed in wicket for things other then cluster replication. Versioning has been one of those reasons. We would use serialization mostly for cloning an object, so that we can keep a reference to its previous state for rolling back a version. With 1.3.1 this has changed dramatically. In order to free up session space (1.2 would keep x pages in session) 1.3.1 only keeps the most current page in session and spools older pages to disk via serialization. So if you hit a page that has a serialization problem and later come back to it via back button and click a link/submit a form you will get a page expired error. My recommendation is to make sure you use detachable models or make your objects serializable. In the meantime, try class MyApplication extends WebApplication { ISessionStore newSessionStore() { return new HttpSessionStore();}} that will turn off disk spooling and will make 1.3 behave more like 1.2 in that regard.
Ok, I'll try this just to see if it can at least solve immediately the problem, then go for some refactoring. My question is: but if I don't need (and don't want) page versioning, and I disable it, is serialization still necessary?
-- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941
