Skip to main content

Bug in Bundle.getResource() in Knopflerfish?

Posted by ss141213 on May 1, 2008 at 12:38 AM PDT

I was running a simple test on multiple OSGi platforms. I am seeing some difference in behavior when I run it on Knopflerfish #2.0.3. Upon investigation, I observed that Bundle.getResource() implementation on Knopflerfish does not use the parent class loader of the bundle even when I set org.osgi.framework.bootdelegation=*.

Here is a simple code that I used to test my theory:

public class Activator implements BundleActivator{

    public void start(BundleContext context) throws Exception {
        Class libClazz = context.getBundle().loadClass("sahoo.Library");
        System.out.println("libClazz = " + libClazz);
        URL libRes = context.getBundle().getResource("sahoo/Library.class");
        System.out.println("libRes = " + libRes);
    }
...

The above code prints non-null value for libClazz, but a null value for libResource. If Bundle.loadClass("sahoo.Library") could load the class, how could Bundle.getResource("sahoo/Library.class") return null? It works as expected in other OSGi implementations.

To ensure that sahoo.Library.class is available in the parent class loader, I wrote a Main class which creates a ClassLoader that has both the knopflerfish framework.jar and my library.jar in search path. I then use that classloader to launch knopflerfish.

Has anyone else faced similar issues? I think this is a serious bug in knopflerfish. I tried to get a confirmation by reporting it in their forum, but no luck. I also tried using the dev forum, but no difference. Is there a better way to ask them questions? I don't know. So I thought I would document what I observed.

Related Topics >>

Comments

Hmm, this might be a bug in KF but it was definitely not in the spirit of OSGi to (ab)use the bootdelegation header in this way. This header was added because an older Sun VM had a bug that picked the wrong class loader. Allowing the com.sun.* packages to be found from the boot class loader was the only way to circumvent this bug. The specification strongly recommends against the use of this header because it breaks modularity badly. It is kind of scary when you need this ... :-) Kind regards, Peter Kriens

tetsing

Hi, just saw your post. We haven't replied, nor had a chance to look into your problem yet, basically since May 1 is a national holiday in most European countries.

You can always send a mail to info@knopflerfish.org

Regards,
Christer

http://www.knopflerfish.org
http://www.makewave.com

This was a bug in Knopflerfish. It is now corrected in the trunk.

It was caused by a changed behavior when moving from R3 to R4 that we had failed to update. The R4 TCK didn't detect the bug either. We will suggest to add a test case for this.

A more detailed description of the problem is (from the changelog)

Bundle.getResource(), Bundle.getResources() and the corresponding methods in the bundle class loader now honors the OSGi specified system property named "org.osgi.framework.bootdelegation". Note that this change breaks the backwards compatibility in our impl. with OSGi R3, since Bundle.getResource() and Bundle.getResources() now returns resources from the class space and not only the bundle-space as in R3.