Hi Neil, somehow I have the feeling, this problem can be solved in a different way.
If the osgi.framework.system.packages / extra is provided including a version qualifier for JavaSE-1.8. Mostly, I see, if provided at all, that these definitions are provided without version attribute. If I understand it correctly in https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess. The resolver preference priorities are resolved exporter before unresolved exporters and then versioned exports before un-versioned. That would mean that the system-bundle with system.packages is always resolved, and would preferred before other bundles. If then also a correct version is provided in the system.packages, it should be the preferred wire before all others. Adding an Import-Package, where an Export-Package exist, could also lead to the situation, where the Import-Package is ignored by the framework: https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-import.export.same.package Or am I missing something here? Regards, Mark Am 26.08.20 um 16:44 schrieb Neil Bartlett:
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 <mailto: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 list equinox-dev@eclipse.org <mailto:equinox-dev@eclipse.org> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev-- Mark Hoffmann E-Mail:mark.hoffm...@web.de <mailto:mark.hoffm...@web.de> _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org <mailto: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
-- 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
