Did some debuging further. Class not found exception occurs when the required class is loaded from TCCL. "Thread.currentThread().getContextClassLoader()" When I checked the TCCL, it's not OSGi aware (it's not create from Felix). TCCL contains the classloader coming from the boot classpath. Is this the accepted behaviour ?
Saminda On Thu, May 22, 2008 at 2:48 PM, Marcel Offermans < [EMAIL PROTECTED]> wrote: > Can you strip the example up to the point where we can have a look at it? > It could be that the class that refuses to load needs something that is not > available. > > Greetings, Marcel > > > On May 22, 2008, at 11:14 , Saminda Abeyruwan wrote: > > "." is present >> >> Saminda >> >> On Thu, May 22, 2008 at 2:33 PM, Marcel Offermans < >> [EMAIL PROTECTED]> wrote: >> >> On May 22, 2008, at 10:09 , Saminda Abeyruwan wrote: >>> >>> Bundle A exports some package "a.b". In addition to this, this bundle >>> >>>> embed >>>> a foo.jar and manifest has Bundle-Classpath: foo.jar >>>> >>>> Bundle B imports package "a.b". Say the activator of bundle B calls a >>>> class >>>> of this package. When this happen, I'm seen a class not found exception >>>> from >>>> a.b class, which is available in foo.jar. When bundle B's class loader >>>> delegates to bundle A's class loader, this shouldn't be a problem. Am I >>>> doing something wrong ? >>>> >>>> >>> If my memory serves me well, you need to explicitly include "." in the >>> bundle classpath, so: >>> >>> Bundle-Classpath: ., foo.jar >>> >>> Greetings, Marcel >>> >>> >>> >> >> -- >> Saminda Abeyruwan >> >> Senior Software Engineer >> WSO2 Inc. - www.wso2.org >> > > -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org
