You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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...
The text was updated successfully, but these errors were encountered:
kriegfrj
changed the title
[junit5] BundleContextExtension using the wrong classloader?
[junit5] BundleContextExtension using the wrong classloader
Nov 4, 2020
We already have class loader access to all the necessary framework types
while the test bundle may not itself have access because it does not
need access.
This simplifies the API a bit, so we refactor to avoid the need to pass
a Class object into the proxy methods.
Fixesosgi#229
Signed-off-by: BJ Hargrave <hargrave@us.ibm.com>
stbischof
pushed a commit
to stbischof/osgi-test
that referenced
this issue
Feb 15, 2021
We already have class loader access to all the necessary framework types
while the test bundle may not itself have access because it does not
need access.
This simplifies the API a bit, so we refactor to avoid the need to pass
a Class object into the proxy methods.
Fixesosgi#229
Signed-off-by: BJ Hargrave <hargrave@us.ibm.com>
stbischof
pushed a commit
to stbischof/osgi-test
that referenced
this issue
Mar 4, 2021
We already have class loader access to all the necessary framework types
while the test bundle may not itself have access because it does not
need access.
This simplifies the API a bit, so we refactor to avoid the need to pass
a Class object into the proxy methods.
Fixesosgi#229
Signed-off-by: BJ Hargrave <hargrave@us.ibm.com>
@chrisr3 contacted us with a
NoClassDefFoundError
he was getting using theServiceExtension
in one of his own tests: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 theBundleContextExtension
instantiates theCloseableBundleContext
, it passes a class from the test bundle to the constructor, which theCloseableBundleContext
then uses to get aClassLoader
for building the dynamic-proxiedBundleContext
. 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 withNoClassDefFoundError
s.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 toorg.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 ofCloseableBundleContext
, all the dependencies that its generated proxies will ever need are known ahead of time, and they should all be available toCloseableBundleContext
'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...
The text was updated successfully, but these errors were encountered: