On Tuesday 16 August 2005 10:33, Martijn Dashorst wrote: > The application server takes that out of the hands of Wicket. Wicket > doesn't have a say in whether or not things will be serialized, and > deserialized. The server takes care of that responsibility.
Ok, so the application server is responsible for this, only it has no way of knowing how to deserialize these objects. > Currently the only solution I can see is to put a proxy in between, > which tries to resolve the objects using the Oscar classloaders. You need to be able to take control of the deserialization process somehow. Perhaps creating a base class that implements writeReplace() and readResolve() would work. If so, that could be the location where you could implement Richard's idea below: > > Is it possible to somehow make serialization/deserialization a process > > control through a bundle/service, so that everything occurs inside of > > Oscar as opposed to the mix and match approach currently being used? The deserialization code could check the framework for a (factory) service that can create the required object. Greetings, Marcel
