Answer»
- OSGi bundles are jar files with METADATA inside. Much of this metadata is in the jar’s manifest, found at META-INF/MANIFEST.MF. This metadata, when read by an OSGi runtime container, is what gives the bundle its power.
- With OSGi, just because a class is public doesn’t mean you can get to it. All bundles INCLUDE an export list of package NAMES, and if a package isn’t in the export list, it doesn’t exist to the outside world. This allows developers to build an extensive internal class hierarchy and minimize the surface area of the bundle’s API without abusing the notion of package-private visibility. A common pattern, for instance, is to PUT interfaces in one package and implementations in another, and only export the interface package.
- All OSGi bundles are given a version number, so it’s possible for an application to simultaneously ACCESS different versions of the same bundle (eg: junit 3.8.1 and junit 4.0.). Since each bundle has it’s own classloader, both bundles classes can coexist in the same JVM.
- OSGi bundles declare which other bundles they depend upon. This allows them to ensure that any dependencies are met before the bundle is resolved. Only resolved bundles can be activated. Because bundles have versions, versioning can be included in the dependency specification, so one bundle can depend on version junit version 3.8.1 and another bundle depend on junit version 4.0.
- In OSGi bundle, there will be an Activator.java class in OSGi which is an optional listener class to be notified of bundle start and stop events.
|
