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
