i though matej did already do something like that, because i think matej did try to avoid double serialization (by us and by the container) So i would say that it would go automatic already
Isn't this the case matej? johan On Nov 21, 2007 10:39 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > Hi, > > When Wicket pages are serialized/deserialized to the page store, they > are serialized/deserialized using the IObjectStreamFactory set in the > Objects class, and (in trunk) the DefaultObjectStreamFactory overrides > the resolveClass method of ObjectInputStream to consult the > application's IClassResolver. This is all good. :-) > > But, the problem is the session itself. The ObjectIn/OutputStreams that > the session is serialized to and deserialized from are the ones provided > by the container, which do not use the IObjectStreamFactory. This causes > problems with session serialization/deserialization in an OSGI > environment. > > I'm not really deeply into the Wicket code, but it seems to me the only > way to really solve this is to make sure the Wicket session is not > directly put in the HTTP session, but instead of it, a SessionHolder > object with a reference to the Wicket session. The SessionHolder can > have readObject/writeObject methods which just read/write the session as > a byte stream using Objects.byteArrayToObject/objectToByteArray. > > That way, when the Session is deserialized the IClassResolver is > consulted (and if the user provides their own IObjectStreamFactory > implementation, it too is used). > > Any comments? > > Regards, > Sebastiaan >
