Java Reference
In-Depth Information
Application
Isolation boundary
Framework instance
B
System
bundle
Access
A
Application objects
C
Figure 13.3 A framework instance represents the system bundle and provides the means to
manage the framework instance as well as interact with deployed bundles.
PROVIDING SERVICES AND USING BUNDLE SERVICES
Luckily, there's no new API to learn when it comes to providing application services to
embedded bundles or using services from them. You learned about providing and
using services in chapter 4, and that knowledge applies here. The only real difference
is that you use the system bundle to do everything, because the application has no
bundle associated with it.
Because you need a BundleContext to register or find services, you use the
BundleContext associated with the system bundle. You can get access to it by calling
getBundleContext() on the framework instance. From there, registering and using
services is pretty much the same as if the application were a bundle. Simple, right? As
you may expect, there is one main constraint.
NOTE An application embedding a framework instance can only interact with
contained bundles using objects whose class definition is the same for both
the application and bundles.
By default, the application on the outside and the bundles on the inside only share
core JVM packages, so it would be possible for the application and bundles to interact
using objects from classes defined in core JVM packages. For example, you can pro-
vide or use java.lang.Runnable services, because you know the application and the
bundles use a common class definition for Runnable . This works out fairly well if
everything you need is in a core JVM package, but this isn't typically the case.
Luckily, there's a rudimentary way to share packages from the application to the
contained bundles via framework configuration. The launching and embedding API
defines two previously mentioned configuration properties for this purpose:
Search WWH ::




Custom Search