Re: [osgi-dev] Parent Class Loader Bootdelegation
Thanks Neil, So I understand that "framework" means the ClassLoader that loaded the system bundle and not the system bundle Class Loader itself. That was my initial understanding. But when I tried to delegate our platform packages via bootdelegation and omitting them from system.packages.extra, I got ClassDefNotFound on them. When I added our platform packages to both bootdelegation and system.packages.extra That helped for the platform packages (though I have other problems) That made me think that the "framework" configuration makes bootdelegation delegate to system bundle itself, which in his turn, import them with system.packages.extra and so gets them from the class loader that loaded him. Hope I didn’t confused you. Eran From: Neil Bartlett Sent: Thursday, March 19, 2020 11:46 AM To: Eran Twili ; OSGi Developer Mail List Subject: Re: [osgi-dev] Parent Class Loader Bootdelegation It looks like you have answered this yourself: "framework" delegates to the classloader that loaded the system bundle, i.e. the OSGi Framework. Bear in mind that that classloader would normally perform parent delegation up the chain, unless you have implemented alternative custom behaviour in any of those classloaders. Neil On Thu, 19 Mar 2020 at 09:42, Eran Twili via osgi-dev mailto:osgi-dev@mail.osgi.org>> wrote: Hi, We're embedding OSGi inside an outer application. Our hosting application (platform) creates several class loaders beneath the jvm system class loader, and from one of them the OSGi FW is created. Class loader hierarchy something like: jvm boot -> jvm ext -> jvm system -> custom1 -> custom2 -> custom3 -> OSGi FW (aka system bundle) We now experience problems with our platform Profiler. How can I make the bootdelegation to delegate to the class loader that loaded the OSGi FW? org.osgi.framework.bundle.parent = ??? to my understanding, setting "app" will delegate to the jvm system class loader. setting "framework" will delegate to the system bundle. Thanks, Eran Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Wiring rules
Thanks Tom that does help. In light of what you said, I have two questions please. 1. Isn't that even for the first set of bundles, the other bundle that exports the same package as the system bundle but with higher version, may be resolved before the importer of that package is resolved? E.g. assume we have two bundles A and B. Package a.b.c version 1.0.0 is exported from system bundle Package a.b.c version 2.0.0 is exported from bundle A Package a.b.c (no version) is imported from bundle B FW is launched for the first time - system bundle is active A and B are installed. A is started (makes A resolved and then active). Now B is started. At this point we have bundle A and system bundle both resolved and exporting package a.b.c, but bundle A with higher version. Doesn't that means that bundle B will be wired to A's export? 1. Regarding the fact that Equinox persist wiring. How is that working with the system property org.osgi.framework.system.packages.extra, which is configurable between FW restarts? I mean, after FW is stopped, we can change the system.extra property, and when we re-launch, the FW starts from persistent state, but the wires to the system bundle must change. Isn't that so? Regards, Eran From: Thomas Watson [mailto:tjwat...@us.ibm.com] Sent: Wednesday, May 09, 2018 5:18 PM To: Eran Twili ; osgi-dev@mail.osgi.org Subject: Re: [osgi-dev] Wiring rules The resolution rule for preferred candidate ordering is, unfortunately, a fluid rule since bundles can be resolved dynamically and in different orders from one run to the next. For the first resolution of a set of bundles your assertion is correct. The system bundle will always be the first bundle to enter the resolved state. So any exports from the system bundle will be preferred for that resolution. But now consider a new set of bundles is installed after the first resolution. If the first resolution contained another bundle that exported the same package name as the system bundle now we are in a state where two bundles are resolved that export the same package. This was not true for the first resolution. Now if that bundle exports the package at a higher version than the system bundle its package version will be preferred for the second resolution. For restarting from a persistent state. That depends on the framework's persistent implementation. The specification does not require that a framework persist the resolution wiring on shutdown. It is acceptable for the framework to start from an unresolved state when launching from a cached set of installed bundles and then re-resolve the bundles as it is launching again. For example, the Felix framework does not persist the resolution wires and re-resolved all installed bundles on restart while the Equinox framework does persist the resolution wiring and will reuse the wiring state on a restart. HTH Tom - Original message - From: Eran Twili via osgi-dev mailto:osgi-dev@mail.osgi.org>> Sent by: osgi-dev-boun...@mail.osgi.org<mailto:osgi-dev-boun...@mail.osgi.org> To: OSGi Developer Mail List mailto:osgi-dev@mail.osgi.org>> Cc: Subject: [osgi-dev] Wiring rules Date: Wed, May 9, 2018 9:01 AM Hi, I have some questions regarding wiring rules. I know that spec says: “The following list defines the preferences, if multiple choices are possible, in order of decreasing priority: •A resolved exporter must be preferred over an unresolved exporter. • An exporter with a higher version is preferred over an exporter with a lower version. •An exporter with a lower bundle ID is preferred over a bundle with a higher ID.” But I need clarification on some nuances: 1. In case same package is exported by system bundle with version 1, and regular bundle with version 2, and the importers aren’t specifying a version. Is it true to say that although regular bundles’ export version is higher, actually the system bundle export will be chosen (since it‘s always resolved first)? Generally this means that system packages will always be preferred, even though there exist a bundle that exports the same package with higher version? 2. Is the later true also after restarting the FW, going up from persistence area? Generally, assuming we never make changes to bundles state after first activation, does wiring can change after stopping the FW and going up again from persistence area? Regards, Eran Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incom
[osgi-dev] Wiring rules
Hi, I have some questions regarding wiring rules. I know that spec says: "The following list defines the preferences, if multiple choices are possible, in order of decreasing priority: *A resolved exporter must be preferred over an unresolved exporter. * An exporter with a higher version is preferred over an exporter with a lower version. *An exporter with a lower bundle ID is preferred over a bundle with a higher ID." But I need clarification on some nuances: 1. In case same package is exported by system bundle with version 1, and regular bundle with version 2, and the importers aren't specifying a version. Is it true to say that although regular bundles' export version is higher, actually the system bundle export will be chosen (since it's always resolved first)? Generally this means that system packages will always be preferred, even though there exist a bundle that exports the same package with higher version? 2. Is the later true also after restarting the FW, going up from persistence area? Generally, assuming we never make changes to bundles state after first activation, does wiring can change after stopping the FW and going up again from persistence area? Regards, Eran Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Bundle starts although no OSGi headers in its Manifest
Hi, We are implementing OSGi in our product (embedding Equinox programmatically). Designing our Bundles installation error handling, we run some tests. Surprisingly, we see that when we install a regular jar archive in the FW, it's getting installed, resolved and even active, without any exception thrown. We also see that it has a regular bundle-id and that his bundle.getSymbolicName() returns null (Aligns with https://wiki.searchtechnologies.com/javadoc/osgi/osgi-javadoc-v41/org/osgi/framework/Bundle.html#getSymbolicName() ) This jar has a Manifest (I think generated by Maven) but it doesn't have any OSGi header in it. This is the Manifest: Manifest-Version: 1.0 Built-By: noname Created-By: Apache Maven 3.2.5 Build-Jdk: 1.8.0_92 Name: Skeleton Rule Build-Time: 2018-01-31 10:49 ArtifactId: skeleton Version: 5.9.2.2-SNAPSHOT GroupId: skel We use org.eclipse.osgi version 3.11.2 (which implements R6) >From what I see in the R6 core spec (section 3.12), the FW should throw an >exception in such case, when installing the jar. 3.12 Bundle Validity The following (non-exhaustive) list of errors causes a bundle to fail to install: * Missing Bundle-SymbolicName. Can anyone please clarify what is the expected behavior? Regards, Eran Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
