Moving toward bundles - OSGi in Action - page 213

if you don't want them, you can remove them by adding this bnd instruction to
jedit-mega.bnd:
-removeheaders: Private-Package,Tool,Bnd-LastModified
The new manifest looks correct, but the real test is yet to come. You must now try to
deploy and run your bundle on an actual OSG i framework. Will it work the first time
or fail with an obscure exception?
RUNNING JEDIT WITH OSGI
You can deploy your jEdit bundle by using the same simple launcher used to launch
the earlier paint examples. Remember, this launcher first installs any bundles found
in the directory and then uses the first Main-Class header it finds to bootstrap the
application. Your manifest already has a Main-Class , so you need to point the
launcher at the jEdit directory, like so:
$ cd ..
$ cp ../../launcher/dist/launcher.jar .
$ java -jar launcher.jar jEdit
Unfortunately, something's not quite right. The bundle installs and the application
starts, but it hangs at the splash screen shown in figure 6.8, and the main jEdit window
never appears.
If you look closely at the top of the stack trace, you see the following warning
message:
java.net.MalformedURLException: Unknown protocol: jeditresource
Why did this work when the bundle was run as a classic application, but not when the
bundle was installed in an OSG i framework? The answer lies in the URL Handlers Service
we discussed briefly back in section 4.6.1. To implement this service, the OSG i frame-
work installs its own URLStreamHandlerFactory , which delegates requests to handlers
installed via the service registry. Unlike the default URLStreamHandlerFactory , this
implementation doesn't automatically scan the class path for URL handlers. Instead, all
Figure 6.8 jEdit when
first run as OSGi bundle