Recently, I started to invest time in osgi learning. I bought Lin Hao's osgi principles and practices and sorted out my knowledge by referring to articles on 51cto and other materials.
The dynamic and disruptive development of osgi lies largely in the design scheme of dependency between bundle in osgi. I personally think this is a valuable part of osgi,
In our daily web development, although it is called disruptive development, the dependency design is not a real module and cannot be used as a plug-and-play, deleted, or ineffective;
In the osgi specification, this "ideal" modularization can be realized, achieving physically isolated module development.
Back to the issue of dependency between bundle,
Share classes between Bundle:
The export package is used to share a specific package with other Bundle by specifying the export package in the bundle manifest.
There are two ways to reference the packages exposed by other bundle. The first is to import the package, and the second is to use the required Bundle Method.
The osgi container creates different classloader for each bundle,
Therefore, each bundle can access classes located in the following locations:
A) All classes in the packages starting with Java. * located in the Java startup class path;
B) classes located in the osgi framework class path, usually have an independent class loader responsible for loading the implementation class and key interface classes of the Framework;
C) classes in the bundle space. These classes are usually included in the jar files related to the bundle and added to other jar packages in the bundle.
D) Import classes in the package
Of course, the entire osgi container cannot only create their own class loaders for each bundle to manage the bundle. osgi also provides parent classloader and system classloader for management.
The loading mechanism of the entire class is:
1: If the package is Java. * Parent classloader
2: If the package defined by boot delegates is also loaded by the parent classloader
3: If it is specified in the import package, the package is loaded by the bundle class loader.
4: The export package in the bundle of required bundle is loaded by the classloader of the bundle.
5: Search for the bundle's classpath
6: if the package in the fragmentbundle is loaded by the classloader of the bundle (the fragment bundle itself does not have classloader)
7: dynamic import package (similar to the import package loading mechanism, but dynamic import is loaded only when the package is actually used at different time points)
At the same time, you can add restrictions on versions, custom metadata, and other methods while using the Export package. You can perform more precise matching based on these metadata when importing the package.