Wicket and Oscar

[Martijn Dashorst <ma...@dashorst.dds.nl>]

Hi all,

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

Re: Wicket and Oscar

["Richard S. Hall" <he...@ungoverned.org>]

Martijn Dashorst wrote:

> Yep, and I think this is not a particular Wicket/Oscar problem but 
> more webapplication/oscar problem.


Well, it is a general problem that arises by trying to use two class 
loaders together where both want to be in control.

> 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, this was a point of confusion for me. I can understand now that you 
are at the mercy of the app server.

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


Without a doubt, you have to make the app server somehow ask Oscar for 
the classes, but even this will be somewhat tricky, since there is no 
way to simply ask Oscar for classes; however, it can be done, I believe.

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


It seems like it would be altering the app server, not the servlet spec.

We have a situation here where OSGi is creating a generic module layer 
for Java, which conceptually is at a lower level. So, by all rights, the 
app server should be a module(s) built on this layer. Since this isn't 
the reality of the situation yet, the only other approach is to make the 
app server aware of the module layer. The approach for doing this, seems 
to be the point of this thread. Correct?

Clearly, the best approach is to find some way to make it invisible to 
the app server.

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


I don't see how this would help. The app server does not have access to 
the classes (as I understand it), only Oscar does. Thus, using the app 
server class loader doesn't help.

If you could make a custom class loader the parent of the app server's 
class loader, then perhaps you could use this as a hook. You could try 
to return classes contained in the bundles through this custom class 
loader; i.e., it would delegate to the bundle class loaders.

-> richard

Re: Wicket and Oscar

[Marcel Offermans <ma...@luminis.nl>]

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

Re: Wicket and Oscar

[Martijn Dashorst <ma...@dashorst.dds.nl>]

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?

Martijn

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

Re: Wicket and Oscar

["Richard S. Hall" <he...@ungoverned.org>]

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