On Tuesday 28 June 2011 12:44 AM, Harald Wellmann wrote:
> 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.
>
Glad, it is working as expected.
>> 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.
>
This is a different feature of your glue code than earlier stated.
Although it is not related to the class loading issue you initially
raised, can you elaborate a bit more about this glue code? What exactly
it is bridging?
Sahoo