Moving toward bundles - OSGi in Action - page 222

If you expect to continue to use your application outside of OSG i—for example, as
a classic Java application—you may be worried about using the service layer in case it ties
you to the OSG i runtime. No problem! You can get the benefits of services without being
tied to OSG i by using component-based dependency injection. Chapters 11 and 12 intro-
duce a number of component models that transparently support services without forc-
ing you to depend on the OSG i API . If you already use dependency injection, moving to
these component models is straightforward; sometimes it's only a matter of reconfigur-
ing the dependency bindings in your original application. If you're itching to try out
these component models, feel free to skip ahead to chapter 11. But make sure you come
back and read the intervening chapters; they'll be an invaluable guide when it comes
to managing, testing, and debugging your new OSG i application.
Let's get back to discussing services. Where might you use services in jEdit? Well,
jEdit has its own home-grown plugin framework for developers to contribute all sorts
of gadgets, tools, and widgets to the GUI . In addition, jEdit uses its own custom class
loader org.gjt.sp.jedit.JARClassLoader to allow hot deployment and removal of
jEdit plugins. Plugins hook back into jEdit by accessing implementation classes and
calling static methods, such as jEdit.getSettingsDirectory() . These static method
calls are convenient, but they make it hard to mock out (or replace) dependencies for
testing purposes.
Instead of relying on static methods, you can change jEdit to use dependency injec-
tion. Plugins then have their dependencies injected, rather than call jEdit directly. After
you replace the static methods calls with dependency injection, it's just another step to
replace the static bindings with dynamic OSG i services (see chapters 11 and 12). This
also simplifies unit testing, because you can swap out the real bindings and put in
stubbed or scripted test implementations. Unfortunately, refactoring jEdit to use
dependency injection throughout is outside the scope of this topic, but you can
use chapters 11 and 12 as a general guide. With this in mind, is there a smaller task that
can help bridge the gap between OSG i bundles and jEdit plugins and make it easier to
use services?
You can consider replacing the jEdit plugin framework with OSG i, much as
Eclipse replaced its original plugin framework. To do this, you have to take the JAR-
ClassLoader and PluginJAR classes and extract a common API that you can then re-
implement using OSG i, as shown in figure 6.10. You use the original jEdit plugin
code when running in classic Java mode and the smaller OSG i mapping layer when
running on an OSG i framework.
Extracting the common plugin API is left as an interesting exercise for you; one
wrinkle is the fact that jEdit assumes plugins are located in the file system, whereas
OSG i supports bundles installed from opaque input streams. The new plugin API can
have methods to iterate over and query JAR file entries to avoid having to know where
the plugin is located. These methods will map nicely to the resource-entry methods
on the OSG i Bundle interface.