felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Building an application out of bundles: bootstrapping
Date Mon, 04 Dec 2006 16:29:25 GMT
Steven E. Harris wrote:
> 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.

This is not entirely accurate. The Felix.start() method accepts a list 
of BundleActivator instances. These passed in activator instances 
effectively become part of the system bundle and their start()/stop() 
methods will be given the system bundle's context so that they can 
install bundles, register services, etc.

> 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).

I don't think this explanation (as I understand it) is completely 
accurate either. The installBundle() operation does not do any extra 
work (or at least not much) if a bundle is already installed. Installed 
bundles are indexed by their location, so on startup if the bundles in 
the autostart property are installed again, the only thing that happens 
is that the existing bundle object is discovered and returned.

The copying, etc. only happens when you create a new profile.

> 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.

Yes, I think it makes sense to deliver Felix-based applications with a 
pre-populated cache. However, this just depends. For some applications, 
you the user may be able to select different configurations when they 
start. The launcher in that case may select a set of bundles to 
autostart based on the selected configuration, etc. But both approaches 
could make sense depending on your application.

> 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
> installed.

This pretty much happens already, since nothing is done if you try to 
install a bundle a second time.

> 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.

In the end, you cannot get around the issue that something has to be 
installed in the framework. It can either be bundles using the autostart 
properties or it can be a custom launcher that uses some other mechanism 
to load bundles, such as the system bundle activator approach mentioned 

-> richard

View raw message