Thanks Jürgen. Here is the same article, with the diagrams included: http://njbartlett.github.io/2011/09/02/uses-constraints.html
Hope it helps. On Fri, 28 Aug 2020 at 13:14, Jürgen Albert <[email protected]> wrote: > Hi, > > it seems as if Neil already described the problem and what might cause the > problem pretty spot on in this blog post: > > https://blogs.paremus.com/2011/09/solving-osgi-uses-constraint-violations/ > > Jürgen. > Am 28/08/2020 um 13:35 schrieb Mark Hoffmann: > > 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 <[email protected]> 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 [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/equinox-dev >> >> -- >> Mark Hoffmann >> >> E-Mail: [email protected] >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/equinox-dev >> > > _______________________________________________ > equinox-dev mailing [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev > > -- > Mark Hoffmann > > E-Mail: [email protected] > > > _______________________________________________ > equinox-dev mailing [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev > > -- > Jürgen Albert > Geschäftsführer > > Data In Motion Consulting GmbH > > Kahlaische Str. 4 > 07745 Jena > > Mobil: 0157-72521634 > E-Mail: [email protected] > Web: www.datainmotion.de > > XING: https://www.xing.com/profile/Juergen_Albert5 > > Rechtliches > > Jena HBR 513025 > > _______________________________________________ > equinox-dev mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
