users@glassfish.java.net

Re: OSGi Web Bundle Classloader Magic

From: Harald Wellmann <harald.wellmann_at_gmx.de>
Date: Mon, 27 Jun 2011 19:16:53 +0200

Am 27.06.2011 06:06, schrieb Sahoo:
> Harald,
>
> What exactly you mean by "W can load classes from B?" Is W loading a
> class from B reflectively?

Sorry, I wasn't too precise: "W can load classes from B _by name_" is
what I mean, using Class.forName() and its own bundle class loader.

> In the context of
> request processing or deployment, GlassFish sets the context class
> loader of the WAB to be a class loader which can load from WAB as well
> as from other bundle's exported packages.
>
Thanks, that answers my question and confirms my assumption. So it's the
context class loader doing the magic.

With Wicket, I found two scenarios which should have bombed, one is
bootstrapping of the users' application class, which is specified by
class name as a filter init parameter in web.xml, and the other one is
page deserialization where Wicket potentially needs to load all sorts of
private classes from user bundles.

The first case is during deployment, the second case during request
processing, and if GlassFish sets the context class loader in both
cases, that explains why my sample works even without the glue code I
implemented to provide access to the required classloaders.

The only thing is, it looks like I'll have to stick with my glue code,
because even knowing that both GlassFish and Pax Jetty do set the
context class loader, it's not safe to assume that all servers will do
the same...

Regards,
Harald