felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven E. Harris" <...@panix.com>
Subject Building an application out of bundles: bootstrapping
Date Fri, 01 Dec 2006 21:56:33 GMT
It took me a day or so to realize that if one starts up Felix with no
felix.auto.install or felix.auto.start property specified, no bundles
can ever be added, as the only (other) way to install a bundle is with
a BundleContext, and the only way to get a BundleContext is with an
Activator's start() method. If we agree on that, then at least one
bundle must be added at startup for Felix to do anything useful.

I started experimenting with creating a "root" bundle that's the sole
thing specified in felix.auto.start, with this "root" bundle's job
being to capture a BundleContext and start up the rest of the
application. Several questions arose.

Using the felix.auto.(install|start) property causes a bundle to be
/installed/ from some URL into the cache. This means that each time
the application starts, some files are inspected and copied. If we're
talking about an application that will be run over and over, is it
sound to think of the cache as durable, meaning that once a bundle is
installed, it will be there the next time the program starts up? If
so, there's a difference between "seeding" a new cache and starting up
a program that's using an already-populated cache.

The first mode -- seeding a new cache, or re-seeding an existing cache
-- is what's shown in the sample Felix programs. It's easy to
understand, but it has a few problems. First, it keeps doing the same
inspecting and copying operations every time the program starts. It
requires that the startup bundles be sitting somewhere accessible --
either taking up space on the disk, or causing a network connection to
reach a remote resource -- even though the program has already
installed these bundles in its cache. Finally, it makes the program
keep on trying to install bundles with fixed names (including their
version number in the examples).

To avoid these problems, would it make sense to deliver a Felix-based
application with pre-populated cache? The set of bundles normally
specified in the felix.auto.(install|start) properties would be in the
cache, perhaps along with the their dependencies.

Maybe the best approach would be if the program could behave
differently depending on whether it's being started up with no cache
(creating one afresh) versus an existing cache. In the first case, it
would seed the cache with a few bundles, while in the second case it
wouldn't bother trying, assuming the necessary bundles are already

This could work if most of the bundles normally specified in the
felix.auto.(install|start) property were available on the disk as a
repository. The "root" bundle could start up and attempt to resolve
some initial requirements with a RepositoryAdmin and a Resolver,
deploying resources to satisfy any unmet requirements. Well, but in
order to even have a RepositoryAdmin, we'd need to have the OBR bundle
installed. Chicken-and-egg problem.

I'm just thinking out loud, but I'd like to hear anyone else's
thoughts on these matters.

Steven E. Harris

View raw message