‘OSGi Demystified’ is a series of articles addressing common OSGi issues in CICS. We offer insight into OSGi, discuss best practices, and provide setup and configuration advice. This is the fifth and final in the series of section 1, to see the previous post discussing OSGi Services, follow this link.


  • Loading of core JRE packages/classes.
  • The OSGi framework and system bundles.
  • Exceptions to the system bundles process that exposes known extension packages to the system automatically.


JRE class visibility, bootdelegation, and system.packages.extra

In OSGi, loading of core JRE packages/classes (java.*) is always delegated to the bootstrap class loader. The bootstrap class loader, unsurprisingly, is the class loader that loaded/bootstraps the OSGi environment, don’t confuse it with Java’s boot class loader. In practice there is only ever one JRE in the system, and so explicit dependency statements are not required to reach the core JRE classes. For that reason, it is never necessary to add a java.* dependency to a bundle manifest. However, application bundles that require extended parts of the JRE must code an Import-Package statement; for example vendor-specific extensions javax.* com.sun.* and com.ibm.* require an import. This is because they are not delegated to the bootstrap class loader and are instead treated as part of the OSGi system.

The OSGi framework provides a system bundle that exposes known extension packages to the system automatically. An application bundle registers its dependency on those extension packages by including an Import statement, just as it does for all other packages provided by normal OSGi bundles. The advantage of this approach is that extensions can be replaced with newer implementations by installing an OSGi bundle that contains the new code.

There is, however, one exception to this process. If a particular package is coded on the OSGi boot delegation list; by means of the org.osgi.framework.bootdelegation property; the package is delegated straight to the boot class loader. This action completely bypasses the OSGi class loading mechanism. Although it is convenient, because no Import statement is required to access boot delegated packages, it restricts the flexibility of OSGi and is not considered best practice for anything but core, single version packages.

Occasionally you may encounter vendor-specific extensions that aren’t automatically added to the system bundle by the OSGi implementation. Don’t be tempted to add them to the bootdelegation list. For these cases, and assuming the package is genuinely available from the vendors JRE, the property -Dorg.osgi.framework.system.packages.extra can be used to add the packages to the system bundle and allow application Imports to resolve. The following JVM profile excerpts show how one might use these properties:

# Override CICS bootdelegation defaults (dangerous! it replaces the existing list and could break CICS integration)
-Dorg.osgi.framework.bootdelegation=com.ibm.xtq.*, com.ibm.xylem.*

# Extend the CICS bootdelegation defaults (a more acceptable way to add packages to boot delegation)

# Extend the System Packages list to expose extra packages through the OSGi system bundle (best approach)
-Dorg.osgi.framework.system.packages.extra=com.ibm.xylem.types, com.ibm.xylem, com.ibm.xtq


In this section we have discussed a whole range of OSGi entertainments from bundle-wiring to OSGi services, and class loaders to bootdelgation. There are many interesting gotchas in Java and OSGi! At CICS Java HQ we use OSGi internally and hope that our experience can help you to realise the full potential of your CICS Java applications. Sit tight for next section of OSGi Demystified exploring common Java and OSGi class loader problems you might encounter in CICS OSGi and Liberty JVM servers.

To find out when the next instalment is available, follow us on Twitter and/or Facebook. And check out all our OSGi blogs here.

Join The Discussion

Your email address will not be published. Required fields are marked *