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.

> 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.

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: thorsten.schoen...@am-soft.de
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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to