Java Reference
In-Depth Information
That's all there is to it. You've successfully created a completely generic launcher
that will work with any
OSG
i R4.2 framework implementation. To use this launcher
with an arbitrary framework implementation, put it on the class path with the
launcher, and you're good to go. But what about situations where you can't convert
your entire application into bundles? In that case, you may want to embed a frame-
work instance inside your application. We'll look into that next.
13.3
Embedding the framework
In some situations, it isn't possible to convert your entire application into bundles,
where everything runs inside the
OSG
i framework. This can happen in legacy situa-
tions where conversion into bundles is prohibitively expensive, or in situations where
there's resistance or uncertainty about converting the entire application. Even in
these sorts of situations, you can use
OSG
i technology for specific needs. For example,
it's not uncommon for Java-based applications to provide a plugin mechanism for
extensibility purposes. If your application has a plugin mechanism or you're thinking
about adding one, an embedded
OSG
i framework can do the trick (in chapter 6, you
saw how to convert jEdit's plugin mechanism to use
OSG
i).
You may be thinking, “Wouldn't I be better off creating my own simple plugin
mechanism in this case?” Typically, the answer is, no. The dynamic class-loading
aspects of plugin mechanisms are difficult to get right. Over time, you'll likely need to
add more advanced features, such as support for library sharing, side-by-side versions,
or native libraries, at which point you'll start to enter complicated territory and have
to reinvent the wheel. By using
OSG
i, all this is taken care of for you, so you can con-
centrate on implementing your application's core functionality. If you're concerned
about the size of
OSG
i frameworks, remember that they're intended to run on embed-
ded devices, and most implementations aren't too hefty. In addition, you get the ben-
efit of having a known standard, which makes it easier for your plugin developers and
provides the opportunity to reuse existing bundles.
Embedding an
OSG
i framework instance into an application may sound pretty
exotic; but thanks to the standard framework launching and embedding
API
, it's
largely the same as launching the framework. You do need to understand some differ-
ences and a few issues; in the remainder of this section, we'll discuss these issues as
well as present an example of embedding a framework instance into an application.
13.3.1
Inside vs. outside
The main issue around embedding a framework instance into an application is the
distinction between being on the
inside
of the framework versus being on the
outside
of
the framework. The bundles deployed into the embedded framework live in a nice
insulated world and know nothing about the outside. Conversely, the application lives
in the external rough-and-tumble world. Figure 13.2 illustrates the situation.
It's possible to traverse the isolation boundary provided by the framework, but the
inside/outside distinction places some constraints on how the application can interact
with installed bundles and vice versa.
