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
