This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have problem with integration of equinox and I think it is just because the system is too paranoid. core.netigso is in platform/core/*.jar and contains org.osgi...Framework class (from felix.jar). It however uses Lookup to find the correct implementation of the Framework, so another module modules/org-...-netbinox.jar can provide equinox.jar. However equinox also contains org.osgi...Framework class. As a result "Will not load class org.osgi...Framework arbitrarily" is reported and the class is not loaded at all and everything is in vain. The org...netbinox module has dependency on core.netigso. As such, it is guaranteed that the right one org.osgi...Framework class will be loaded and shared between both modules. The "Will not load..." check shall recognize this situation and allow the class to be loaded. Am I right? I think so (and I can reimplement the check myself), I am just not 100% sure. PS: Splitting OSGi API into core.netigso is unlikely to help as both felix and equinox will still continue to ship their own copy (as usual in OSGi world). Removing the class from equinox.jar sounds dangerous and did not work for some reason anyway.
Created attachment 93509 [details] I can get around the problem using ServiceLoader, but I'd rather see proper fix
So modules A and B both supply class p.C, yet B depends on A, A exports p.*, and so B's copy would never actually be used because it is shadowed? In that case it is true that attempts to load p.C from the SCL ought to go to A without complaints. The situation is a bit pathological and so probably never came up before. I will try to reproduce in a unit test and fix. BTW your patch to netigso was I guess accidentally committed as part of 803ecf76ee9a. (Please use 'hg out -pv' to prevent this kind of mistake in the future.) I will revert it together with the fix for this issue. > both felix and equinox will still continue to ship their own copy Which is why we would delete org.osgi.** classes from felix.jar or equinox.jar before bundling them in NB, if we were to create an OSGi API lib wrapper module. That is the solution I would really recommend in the long term, though I can try to fix this issue as a short-term workaround.
After looking at it more closely, I do not see a way to implement this without throwing out the benefits of the package coverage cache. While I can easily make the "ambiguous delegation" error go away, the wrong class will be loaded (in your case from equinox.jar rather than felix.jar).
Created attachment 93537 [details] How to test a potential fix; l5.loadClass(A) is the biggest problem
Right, I can see solutions for previous tests, but l5.loadClass(A) is really hard. If we have another way to eliminate the problem (bug 179470), then let's delay fixing this problem.