[junit5] BundleContextExtension using the wrong classloader

[kriegfrj]

@chrisr3 contacted us with a NoClassDefFoundError he was getting using the ServiceExtension in one of his own tests:

java.lang.NoClassDefFoundError: org.osgi.framework.ServiceListener not found by impl-tests [5]
        at com.sun.proxy.$Proxy14.<clinit>(Unknown Source)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:739)
        at org.osgi.test.common.context.CloseableBundleContext.proxy(CloseableBundleContext.java:84)
        at org.osgi.test.junit5.context.BundleContextExtension$CloseableResourceBundleContext.<init>(BundleContextExtension.java:192)

It was a very simple test, and that was actually what exposed the problem - the test doesn't actually import org.osgi.framework - it is simple enough that it doesn't need to. However, when the BundleContextExtension instantiates the CloseableBundleContext, it passes a class from the test bundle to the constructor, which the CloseableBundleContext then uses to get a ClassLoader for building the dynamic-proxied BundleContext. So if the host test bundle doesn't import classes that the proxy class implementation requires, then the dynamic proxy class will fail to load with NoClassDefFoundErrors.

I suspect that we've been getting away with it in our own tests because our own tests are directly importing org.osgi.framework for their own purposes anyway. But @chrisr3's example highlighted a legitimate use case where the test class/bundle may have no direct need to link to org.osgi.framework. I managed to set up a workaround for him simply by creating a reference to the missing class (and hence forcing Bnd to generate an import for it for his own test class).

I think that the solution here is not to use the test bundle's class loader, but perhaps the CloseableBundleContext's own class loader. I know that AssertJ's soft proxying does this, but that's because it must be able to generate dynamic proxies of proxying arbitrary user classes defined in an arbitrary classloaders with arbitrary dependencies. In the case of CloseableBundleContext, all the dependencies that its generated proxies will ever need are known ahead of time, and they should all be available to CloseableBundleContext's class loader.

It will still be important to use the "host" class at the end of the BundleContext delegation chain, so that when the test makes changes to the bundle context it does so to its own bundle context.

Coming up with a regression test for this could be tricky though...