felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Dashorst <mart...@dashorst.dds.nl>
Subject Re: Wicket and Oscar
Date Tue, 16 Aug 2005 08:33:06 GMT
Richard S. Hall wrote:

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

Yep, and I think this is not a particular Wicket/Oscar problem but more 
webapplication/oscar problem. It arises mainly in Wicket, because 
creating custom components and putting them into bundles is sooooo nice. 
Wicket is a web application framework, and you'll probably be introduced 
to Wicket sooner or later by Timothy Bennett, if I'm not mistaken ;-).

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

What I've done in my webapplication is create (Wicket) components that 
reside in bundles. We use Oscar to get access to those components, as 
they just provide a service. So the webapplication itself only knows the 
interfaces and doesn't know where it gets its objects from. The same 
goes for Wicket. Wicket gets the components delivered by Oscar.

I'll try to invest some time in creating a demo app later today.

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

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.

Currently the only solution I can see is to put a proxy in between, 
which tries to resolve the objects using the Oscar classloaders.

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

That could be a novel approach, but I think we'd need to alter the 
servlet spec for that to happen ;-).

Is there a requirement that Oscar can't use different classloading 
strategies? For instance, use the classloader of the application server 
instead of its own?


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