Hallo Thorsten, On Sun, Nov 23, 2014 at 1:02 PM, Thorsten Schöning <[email protected]> wrote:
> Guten Tag Martin Grigorov, > am Sonntag, 23. November 2014 um 11:22 schrieben Sie: > > > You are experiencing Tomcat Session Persistence - > > > http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts > > Just disable it for development to avoid such kind of problems. > > But the exception clearly comes from wicket's page store, I already > found the code where the exception is captured and rethrown as > RuntimeException. I really doubt this is a problem of the Tomcat. > Here is what happens: 1) Wicket stores a Page into the HTTP session 2) Tomcat shuts down and persists all HTTP sessions into the disk 3) you deploy and new version of the app (with incompatible changes in the classes, like renaming a class) 4) you start Tomcat and it tries to load the persisted sessions 4.1) Since Wicket stores its data as org.apache.wicket.pageStore.DefaultPageStore.SerializedPage (a triple of pageId (int) / sessionId (String) / pageData (byte[])) it is Wicket's job to deserialize the pageData byte[] to SomePage instance. That's why you think Wicket is to blame here. But even if there was a Page stored as an attribute in the http session then Tomcat would fail the same way since there is no such class in the webapp class loader anymore. In both cases I think Tomcat will just log an error that an old session cannot be loaded and continue with the start of the application. Am I correct or Tomcat fails to start ? Please paste the complete exception if I am not correct. > > > 122: return ois.readObject(); > > at > org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:122) > > java.lang.RuntimeException: Could not deserialize object from byte[] > > throw new RuntimeException("Could not deserialize object from byte[]", > cnfx); > > Additionally, deactivating this feature for development only in Tomcat > wouldn't change anything, if I update the production system after > refactoring I would get the same error there of course. > No. Wicket cleans up its data storages at session invalidation time (per sessionId) or at application stop (for all sessions). So there is nothing to load at start time and no knowledge about old stuff. > > From looking at the code I think what I would need to do instead is > create my own delegating serializer, which encapsulates the default > Wicket one, catches the problematic exception and returns null instead > of throwing the exception. It looks like that all code mentioned in > the stacktrace is using null if things are not found or such and would > ultimately lead to PageProvider.isNewPageInstance believing that a new > instance is needed: > > > public boolean isNewPageInstance() > > { > > boolean isNew = pageInstance == null; > > if (isNew && pageId != null) > > { > > IRequestablePage storedPageInstance = > getStoredPage(pageId); > > if (storedPageInstance != null) > > { > > pageInstance = > storedPageInstance; > > isNew = false; > > } > > } > > > > return isNew; > > } > > storedPageInstance would simply be null when using my own serializer. > From my opinion this should be a at least configurable default > behavior in Wicket anyways, I don't see how else it can handle things > like refactoring with using it's own page store of serialized Java > classes. It must ignore ClassNotFoundException in such cases somehow > because it's a perfectly valid situation. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: [email protected] > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
