Java Reference
In-Depth Information
additional checks and support for advanced modularity features offered by
OSG
i R4
specifications and beyond.
After you've captured enough bundle details to satisfactorily describe your
JAR
file,
the next thing to decide is which packages it should export to other bundles in the
framework.
6.1.2
Exporting packages
Most bundles export at least one package, but a bundle doesn't have to export any.
Bundles providing service implementations via the service registry don't have to
export any packages if they import their service
API
from another bundle. This is
because their implementation is shared indirectly via the service registry and accessed
using the shared
API
, as illustrated in figure 6.2. But what about the package contain-
ing the
Bundle-Activator
class? Doesn't that need to be exported? No, you don't
need to export the package containing the bundle activator unless you want to share it
with other bundles. Best practice is to keep it private. As long as the activator class has
a
public
modifier, the framework can load it, even if it belongs to an internal, non-
exported package. The question remains: when is it necessary for you to export pack-
ages, and which packages in your
JAR
file do you need to export?
getServiceReference
registerService
Service
registry
Activator
Activator
getService
Impl
Impl
API
Figure 6.2
Sharing implementations without exporting their packages
SELECTING EXPORTED PACKAGES
The classic, non-
OSG
i approach is to export everything and make the entire con-
tents of the
JAR
file visible. For
API
-only
JAR
files, this is fine; but for implementation
JAR
files, you don't want to expose internal details. Clients might then use and rely
on these internal classes by mistake. As you'll see in a moment, exporting everything
also increases the chance of conflicts among bundles containing the same package,
particularly when they provide a different set of classes in those packages. When
you're new to
OSG
i, exporting everything can look like a reasonable choice to begin
with, especially if you don't know precisely where the public
API
begins or ends. On
the contrary: you should try to trim down the list of exported packages as soon as
you have a working bundle.
Let's use a real-world example to demonstrate how to select your exports. Here are
some of the packages containing classes and resources inside the core BeanUtils 1.8.0
library from Apache Commons (
http://commons.apache.org/beanutils/
):
