Page History

...

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

...

are the sling.bootdelegation properties used ?

Sling uses the sling.bootdelegation.class property name prefix to define lists of classes that must be added to Sling supports the org.osgi.framework.bootdelegation property to list additional classes to be used from the environment by interpreting Sling configuration properties starting with sling.bootdelegation (This is done . In case you want to have a closer look, this is implemented in the org.apache.sling.launcher.app.Sling.resolve() method).

If a Sling property name starts with the prefix sling.bootdelegation.class. prefix, the list of packages defined as the property value is only appended to the org.osgi.framework.bootdelegation property, but only if the fully qualified class taken from the rest of the property name exists in the parent class loader.

Here's an example, from the jcr-client.properties file:

sling.bootdelegation.class.javax.jcr.Repository = \
 javax.jcr, \
 javax.jcr.lock, \
 javax.jcr.nodetype, \
 javax.jcr.observation, \
 javax.jcr.query, \
 javax.jcr.util, \
 javax.jcr.version

This means that, if the javax.jcr.Repository class is available in the parent class loader, all packages listed will be added to the org.osgi.framework.bootdelegation, making the corresponding classes available to OSGi bundles.

If the property name does not start with this sling.bootdelegation.class. property, the list of packages is just appended to the org.osgi.framework.bootdelegation property.

...