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 <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,
visithttps://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
--
Jürgen Albert
Geschäftsführer
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: 0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de
XING: https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev
