felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Wicket and Oscar
Date Tue, 16 Aug 2005 01:53:25 GMT
This sounds like a tricky situation. The difficulty here is that we 
cannot have two entities thinking they are in control of class loading.

I am not familiar with Wicket at all. I am confused about 
deserialization. Are the objects being serialized from bundles? If so, 
how does Wicket find the classes in the first place? Are the 
deserialized classes also [or only] on the class path?

Is there any hook for extending Wicket to use a different class loader 
when deserializing?

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?

-> richard

Martijn Dashorst wrote:

> I've a web application that uses Oscar for plugin management and 
> Wicket for generating the GUI. On our development list we have a 
> problem with how to serialize and deserialize objects coming from 
> within Oscar bundles. This is necessary when running a Wicket 
> application on a cluster, or when the httpsession is stored on disk or 
> in a database.
> Our main concern is that the application server does not know about 
> the objects loaded through Oscar, as Oscar uses its own classloader. 
> So serialization will happen, but when deserialization kicks in, the 
> application server's classloader will instantiate the object, and the 
> object will live outside the Oscar bundle, and not be connected in any 
> way to Oscar.
> For business objects, this may not be a big problem (can be solved by 
> not storing the object itself, but an ID of sorts to resolve the 
> object after deserialization), but for packaged resources in the 
> bundle, for instance markup, javascript, images, it can be.
> Do you have any ideas on how to tackle this problem?
> With regards,
> Martijn Dashorst

View raw message