Figure 12.4 If the containing folder of a configuration file, or other resource, isn't explicitly exported
as a package by Bundle B, it won't be visible in the class space of Bundle A.
by the library. If the classpath isn't flat, resources may not be visible, causing resource
loading to fail (see figure 12.4).
Is everything doomed to failure when classes or resources are loaded by reflection?
Not at all—all that's required to make it work is to follow the normal OSG i rules for
classloading. Anything that is to be loaded must have its package exported by the own-
ing bundle. This applies to Java code, unsurprisingly, and also to file resources, which
may surprise you. For example, if a fancyfoods.config bundle wants to make a fancy-
foods/config/properties/ff.properties file available to other bundles, fancyfoods.con-
fig must include the following in its manifest (even if fancyfoods/config/
properties doesn't have any Java classes in it!):
Similarly, bundles trying to load the ff.properties file must import the fancyfoods
.config.properties pseudo-package. The same is true for any classes they want to load
reflectively. What happens if the package isn't known at compile time? This is where
DynamicImport-Package can be useful—more on that in section 12.3.3.
Even if you were extremely careful to export your configuration package from the
application bundle and import it into the library, you could still only have one config-
uration file package wired at a time. If another provider of the package came along,
then one or the other of you would end up using the wrong configuration!
Even in the absence of OSG i, these classloading problems are sometimes visible in
Java, particularly in Java EE , where part of the runtime might need to load a class from
the application. In these cases, Java makes use of something called the thread context