Mastering modularity - OSGi in Action - page 41

start with how OSG i searches bundles internally for code, followed by how OSG i exter-
nally exposes internal code, and finally how external code is made visible to internal
bundle code. Let's get started.
INTERNAL BUNDLE CLASS PATH
Whereas standard JAR files are implicitly searched for internal classes in all directories
from the root of the JAR file as if they were package names, OSG i uses a more explicit
approach called the bundle class path . Like the standard Java class path concept, the
bundle class path is a list of locations to search for classes. The difference is the bun-
dle class path refers to locations inside the bundle JAR file.
BUNDLE-CLASSPATH An ordered, comma-separated list of relative bundle JAR
file locations to be searched for class and resource requests.
When a given bundle class needs another class in the same bundle, the entire bundle
class path of the containing bundle is searched to find the class. Classes in the same
bundle have access to all code reachable on their bundle class path. Let's examine the
syntax for declaring it.
Bundles declare their internal class path using the Bundle-ClassPath manifest
header. The bundle class path behaves in the same way as the global class path in
terms of the search algorithm, so you can refer to figure 2.10 to see how this behaves;
but in this case, the scope is limited to classes contained in the bundle. With Bundle-
ClassPath , you can specify a list of paths in the bundle where the class loader should
look for classes or resources. For example:
Bundle-ClassPath: .,other-classes/,embedded.jar
This tells the OSG i framework where to search inside the bundle for classes. The
period ( . ) signifies the bundle JAR file. For this example, the bundle is searched first
for root-relative packages, then in the folder called other-classes, and finally in the
embedded JAR in the bundle. The ordering is important, because the bundle class
path entries are searched in the declared order.
Bundle-ClassPath is somewhat unique, because OSG i manifest headers don't nor-
mally have default values. If you don't specify a value, the framework supplies a default
value of period ( .) . Why does Bundle-ClassPath have a default value? The answer is
related to how standard JAR files are searched for classes. The bundle class path value
of . corresponds to the internal search policy of standard JAR files. Putting . on your
bundle class path likewise treats all root-relative directories as if they were packages
when searching for classes. Making . the default gives both standard and bundle JAR
files the same default internal search policy.
NOTE It's important to understand that the default value of Bundle-Class-
Path is . if and only if there is no specified value, which isn't the same as say-
ing the value . is included on the bundle class path by default. In other
words, if you specify a value for Bundle-ClassPath , then . is included only if
you explicitly specify it in your comma-separated list of locations. If you spec-
ify a value and don't include . , then root-relative directories aren't searched
when looking for classes in the bundle JAR file.