Page History

...

1. org.osgi.framework.bootdelegation – All classes matching any entry in this list are always loaded from the parent class loader and not through the OSGi framework infrastructure. This property is a comma separated list of package names. A package name may be terminated by a wildcard character such that any package starting with the list entry matches the entry and thus will be used from the parent class loader.
2. org.osgi.framework.system.packages – Additional package declarations for packages to be exported from the system bundle. This property is a simple package declaration list just like any Export-Package manifest header. In a sense the org.osgi.framework.system.packages property may be seen as the Export-Package manifest header of the system bundle. Namely these entries may not contain wildcards (as is allowed for the bootdelegation property) and may contain directives and attributes such as the uses directive and the version attribute. It is recommended to provide this additional information to help in resolving the bundles. The OSGi Core Specification even prescribes the use of the uses directive.

The problem with the org.osgi.framework.bootdelegation property is, that it completely bypasses any bundle import wirings and just asks the parent classloader. Such situations are not easily recognizable. Therefore the Sling Console will be enhanced to mark any package import which matchs an entry in the org.osgi.framework.bootdelegation appropriately (SLING-148).

Also note, that any package listed as an import in a bundle must be resolveable for the bundle resolve. The import resolution process does not take the org.osgi.framework.bootdelegation configuration into account. This means, that regardless of whether a package is listed in the org.osgi.framework.bootdelegation property or not, if the package is listed as a required import in the Import-Package header, it must be exported by some other bundle.

How does Sling support the org.osgi.framework.bootdelegation Property ?

...

Should the org.osgi.framework.bootdelegation or the org.osgi.framework.system.packages Property be used ?

So, what mechanism should be used ? The answer is, that it depends.

Most of the time, you will want to use the org.osgi.framework.bootdelegation property short-circuits system.packages property. Because this property ensures that you will allways benefit from the normal class resolution process, as for each class of a package listed in the property, the parent class loader is asked. If the parent class loader finds the class, fine. Otherwise the class is not found and an exception is thrown. That is wirings are completely ignored for these classes.mechanism through package imports and exports.

This allows creating the bundles normally by having the package import lists being built according to the packages used by the bundle classes. For example you may use the Apache Felix Maven Bundle Plugin to build your OSGi bundles and the imports are automatically calculated (by default).

The drawback of this method is, that there may be bundles in your system, which export packages also On the other hand the packages listed in the org.osgi.framework.system.packages property are used to enhance the list of exported packages of the system bundle. As such these packages are used just as any packages are used to resolve bundles. So these packages from a bundle point of view are exactly the same as any normal exported package declared in the Export-Package manifest header. In a sense the . Depending on the export version, the wrong package may be bound. So to prevent such collisions you should not install such bundles.

An example of such a declaration is the Servlet API packages (javax.servlet, javax.servlet.http and javax.servlet.resources). These packages are imported into the OSGi framework by the SlingServlet of the launcher/webapp project as part of the org.osgi.framework.system.packages property. To have this work correctly, no bundle should export the respective packages. In the case of Sling, this means, the org.apache.felix.commons.sling-api bundle must not be installed.

If on the other hand you cannot prevent the installation of such bundles and hence the export of the respective packages, you might want to set may be seen as the Export-Package manifest header of the system bundle.The problem with the org.osgi.framework.bootdelegation property conditionally as described above in the answer to how this property is supported in Sling. This ensures the property is , that it completely bypasses any bundle import wirings and just asks the parent classloader. Such situations are not easily recognizable. Therefore the Sling Console will be enhanced to mark any package import which matchs an entry in only set, if the classes are actually available. This should be used as a fall back only, if the org.osgi.framework.bootdelegation appropriately (SLING-148).system.packages method does not work.