Delving deeper into Modularity

Pubudu Dissanayake

Recap

Agenda ● OSGI Classloading ● Processing Import packages and Export Packages● Processing OSGI core classes and Java core Classes ● Optional Imports and Dynamic Imports ● Requiring bundles● Fragment bundles● Extension Bundles

OSGi Classloading

● Bundle-SymbolicName● Bundle-Version● Import-Package● Export-Package● Require-Bundle● Fragment Bundle

OSGI Classloading

Class Loader Delegation model

● The parent class loader (normally java.* packages from the boot class path)● Imported packages● Required bundles● The bundle's class path (private packages)● Attached fragments

A class space for a given bundle can contain classes from

Class-search Order OSGi framework to perform sophisticated searching on behalf of bundles for their contained and needed classes

● If the class is from a package starting with java, the parent class loader is asked for the class. If the class is found, it’s used. If there is no such class, the search ends with an exception.

● If the class is from a package imported by the bundle, the framework asks the exporting bundle for the class. If the class is found, it’s used. If there is no such class, the search ends with an exception.

● The bundle class path is searched for the class. If it’s found, it’s used. If there is no such class, the search ends with an exception.

The classloader hierarchy

Bundle Registry

● The framework maintains a “bundle registry” consisting of a Bundle instance representing each loaded jarfile.

● The bundle instance in turn contains a custom Classloader instance which is used to load classes from its jar file.

● The bundle instance holds information extracted from the MANIFEST.MF file within the jar file, in particular the bundle version and list of imported and exported packages

Processing Import-Package declarations

Import-Package: org.osgi.framework; version="1.3.0"

● Locates a suitably matching entry exported by a bundle in the bundle registry○ If this fails, then processing stops and the bundle is marked

as “installed but not resolved”● Adds an entry to a local map of (packagename=>classloader)

If all imports can be resolved, then the classloader marks itself as being in RESOLVED state

Processing Export-Package declarations

Unlike “import-package” declarations, these are more passive; they simply tell other bundles that they can use this bundle’s classloader as a source of the specified package.

Export-Package: org.foo.shape; org.foo.other; version="2.0.0"

Resolving OSGi core classes

● The OSGi core jar file is on the normal classpath

And so can see both the JDK and potentially any other jar files on the normal classpath.

When an API from this jar file is used to create an OSGi “environment”, it automatically creates a dummy “system” bundle whose classloader can see the OSGi standard classes.

Resolving classes from the Java standard libraries

For other packages that are in the $JRE_HOME/lib/*.jar files

Bundles can then use normal Import-Package statements which causes lookups of such classes to be delegated to the OSGi system bundle’s classloader which is able to resolve them.

● The OSGi startup code simply makes them “exports” of the OSGi system bundle.

Loosening your imports

To import a package, you must know the name of a package in advance,

but this isn’t always possible !!

● Optional Imports

● Dynamic Imports

Optional Imports

Dynamic Imports

Optional Imports Vs Dynamic Imports

● Optional/dynamic imports never cause a bundle to be unable to resolve

● Your bundle code must be prepared to catch ClassNotFoundException s for the optionally/dynamically imported packages.

Similarities

Differences● The framework attempts to resolve an Optional import package once

when the associated bundle is resolved. Dynamic import package, the framework attempts to resolve it at execution time

● Fwk trying to resolve the Dynamic-imports each time it executes

Require-bundleThe OSGi specification also supports a module-level dependency concept called a Require-Bundle

Require-Bundle is just a brittle way to import packages,because it specifies who instead of what.

Bundle Fragments

Fragment-Host: org.foo.hostbundle; bundle-version="[1.0.0,1.1.0)"

● Fragments are not bundles themselves, but instead “additional resources” for the bundle specified by {bundle-name}

● The fragment is “merged into” the specified bundle at runtime.

● A host bundle is technically usable without fragments, but the fragments aren’t usable without a host

● Fragment bundles must be installed before their host bundles.

Extension Bundles

● Extension bundles can deliver optional parts of the Framework implementation or provide functionality that must reside on the boot class path.

● These packages cannot be provided by the normal import/export mechanisms

● Framework extensions are necessary to provide implementation aspects of the Framework.

Fragment-Host: com.acme.impl.framework; extension:=framework

Specific Framework implementation.

Boot class path extension bundle

Fragment-Host: system.bundle; extension:=bootclasspath

Thank you :)

References

● http://moi.vonos.net/java/osgi-classloaders/

● http://blog.osgi.org/2011/05/what-you-should-know-about-class.html

● OSGi in Action: Creating Modular Applications in Java by: Richard Hall, Karl Pauls, Stuart McCulloch, David Savage (01 May 2011)