On Monday 27 June 2011 10:46 PM, Harald Wellmann wrote:
> 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.
That does not sound correct. W's class loader can't load B's class. Are
you sure W uses its own class loader in the argument as opposed to
thread's context 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...
The Servlet spec, not OSGi Web Applications spec, governs the web
container. AFAIK, a web container must set the web application's class
loader as the context class loader during loading and request
processing. So, I don't think your glue code is needed any compliant
container.
Sahoo