I'm not sure that class loading order is even relevant here. The stack trace linked by Brian was an OSGi resolution error... resolution happens before a Bundle ClassLoader is constructed and therefore before the bundle attempts to load any class name.
Neil On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann <mark.hoffm...@web.de> wrote: > Hi, > > I dont think that this is final solution for that problem. > > The class finding search order is defined in OSGi: > > > https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder > > That mean finding a class to be loaded will be initially done using the > boot delegation (Step 2 in this case). If defined correctly the following > will happen: > > Java 1.8 - delegate to parent class loader an load javax.annotation from > there (no matter, if you have an bundle provided for that package) > > Java 11 - cannot find javax.annotation over boot-delegation, go on with > Import-Package or Require-Bundle > > Either provide a org.osgi.framework.bootdelegation=javax.* as property to > activate boot-delegation or you can use the existing profiles instead. > > The Profiles are defined in Equinox: > > > https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile > > You can find the property: org.osgi.framework.bootdelegation there with a > definition for javax.* > > To make Equinox use this profile (I dont know, if this happens by default) > via launcher, you should provide the osgi.java.profile=file:/ > <your-path>/JavaSE-1.8.profile > > If you take the profile, then you have to additionally provide the > property: osgi.java.profile.bootdelegation=override, so that Equinox takes > the profile boot delegation entries. instead of already defined ones > > With the correct boot-delegation configuration, always that same class > loader will be taken for this constellation, no matter, if in Java 1.8 or > 11. The same applies to JAXB problems. > > https://wiki.eclipse.org/Equinox_Boot_Delegation > > > Regards, > > Mark > > > Am 21.08.20 um 22:43 schrieb Brian de Alwis: > > Unfortunately javax.annotation *package-uses* issues have returned > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=566085> :( > > The effort to replace the no-longer maintained Spotify Docker > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284>Client > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284> (bug 558284) > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284> introduced a new > version of the javax.annotation bundle into Orbit > <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/161789> based on Jakarta > EE’s somewhat recently released javax.annotation bundle with version 1.3.5 > <https://search.maven.org/artifact/jakarta.annotation/jakarta.annotation-api/1.3.5/jar>. > This bundle doesn’t use the same approach used for the javax.annotation > 1.2.0 bundle <https://bugs.eclipse.org/bugs/show_bug.cgi?id=462686#c27> to > use import-what-you-export *and* requiring system.bundle. > > The issue only occurs on Java 8 and has been seen in the wild > <https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3623>. > I suspect it has not been more widespread due to increased adoption of Java > 11. > > I’ve pushed up a fix to the javax.annotation 1.3.5 bundle > <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/167718>. I think the > risk is small, but given that we’re in RC season, it would be good to get > some more eyes on this. > > If you have concerns, please comment on Bug 566085 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=566085>. > > Brian. > > _______________________________________________ > equinox-dev mailing listequinox-...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev > > -- > Mark Hoffmann > > E-Mail: mark.hoffm...@web.de > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
