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