6. ● 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
7. 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.
9. 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
10. 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
11. 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"
12. 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.
13. 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.
14. 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
17. 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
18. Require-bundle
The 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.
19.
20. 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.
21. 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
