Delving Deeper Into OSGI Modularity
-
Upload
pubudu-lasal-dissanayake -
Category
Software
-
view
166 -
download
2
description
Transcript of Delving Deeper Into OSGI Modularity
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)