Frequently Asked Questions
This page lists a series of common questions and answers. It is of course work in progress ...
Accessing Classes from the Environment
Mostly when using the Sling Web Application, that is running Sling inside a web application deployed into some servlet container, you might want to share classes between the servlet container and Sling. Some examples of such sharing are:
- Accessing EJB from the Application Server
- Sharing classe with another web application such as a Jackrabbit instance
- Using other container features
For such cases the OSGi Core Specification provides a functionality to declare such class sharing. The functionality is defined in terms of two Framework properties org.osgi.framework.system.packages
and org.osgi.framework.bootdelegation
:
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.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 anyExport-Package
manifest header. Namely these entries may not contain wildcards (as is allowed for thebootdelegation
property) and may contain directives and attributes such as theuses
directive and theversion
attribute. It is recommended to provide this additional information to help in resolving the bundles. The OSGi Core Specification even prescribes the use of theuses
directive.
How does Sling support the org.osgi.framework.bootdelegation
Property ?
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 the org.apache.sling.launcher.app.Sling.resolve()
method).
If a property starts with the prefix sling.bootdelegation.class.
the list of packages defined as the property value is only appended to the org.osgi.framework.bootdelegation
property if the fully qualified class taken from the rest of the property name exists in the parent class loader.
If the property does not start with this sling.bootdelegation.class.
property, the list of packages is just appended to the org.osgi.framework.bootdelegation
property.
How dose Sling support the org.osgi.framework.system.packages
Property ?
Currently extending the org.osgi.framework.system.packages
property in a Sling configuration file is only possibly by setting the org.apache.sling.launcher.system.packages
property. The value of this property, which must start with a comma, is just appended to the org.osgi.framewrok.system.packages
property.
A more elaborate support as is supported for the org.osgi.framework.bootdelegation
Property is being prepared (SLING-147).
Should the org.osgi.framework.bootdelegation
or the org.osgi.framework.system.packages
Property be used ?
The org.osgi.framework.bootdelegation
property short-circuits 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.
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 org.osgi.framework.system.packages
property may be seen as the Export-Package
manifest header of the system bundle.
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).