Am 27.06.2011 19:33, schrieb Sahoo:
> 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?
You're absolutely right, I'll try again: W cannot load classes from B by
name using its own (i.e. W's) bundle class loader, but if the thread
context class loader it set to B's bundle class loader, it will work.
And Wicket does use the thread context class loader to load the user's
application class.
> 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.
Ok, thanks for this pointer - I'll take a look at the Servlet spec then.
> So, I don't think your glue code is needed any compliant
> container.
>
Yes, so it seems my glue stuff is not needed to load the application
class by name. But it also lets you look up the application from the
OSGi service registry instead of creating a new instance, which is handy
if you need to inject required services via DS or Blueprint.
Thanks,
Harald