However, this still leaves all the other objects in the session serialized by the container. Thus if I extend WebSession and add my own fields, they will be serialized/deserialized by the container and bypass IObjectStreamFactory. This is a problem if you store objects with classes from different OSGI bundles in your session.
Regards, Sebastiaan Johan Compagner wrote:
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
smime.p7s
Description: S/MIME Cryptographic Signature
