That's about right. So what I have in my test setup is a stripped-down Karaf with only Felix framework, the OSGi compendium bundle and my initial provisioning bundle. Then I have to set a system or framework property "provisioning.reference" with the URL to my provisioning ZIP (currently just a file URL for testing). I can optionally set "provisioning.spid" to give it a unique identifier but that can also be set by the management agent later.
The initial provisioning service downloads that ZIP and installs all the bundles (embedded or referenced by URL) in the framework and gathers text and binary properties in the information dictionary. That information dictionary can later be accessed through the ProvisioningService that is registered by the initial provisioning service. If there's a "provisioning.start.bundle" it starts the bundle with the given location, i.e. it starts at most one bundle per ZIP. The rest of the bundles are only installed. I actually wrote a generic bootstrap agent that takes note of the installed bundles, remembers them as the first-level management agent bundles and starts them all. That way I can install the actual management agent with one ZIP without the need for an additional mechanism to download and install the actual management agent. And I might be able to reset the service platform to its initial state if I want to. If the ZIP has a property called "provisioning.reference" it downloads another provisioning ZIP and repeats the process above. This loop can happen indefinitely. I'm currently experimenting with deploying Apache ACE this way to check if it fits my additional needs. Another management agent could just download a set of deployment package and install these (well, ACE does that, too). So, yes, that's bootstrapping an OSGi runtime. Of course, you still have to install a container/starter for the OSGi framework. I've chosen Karaf because it already has daemon support. How that container/starter gets on a particular server is a different question so the initial provisioning service falls a bit short, but you've got to start somewhere, right? What I like about the mechanism is the easiness of the setup. The framework, two bundles, a property and a starter to get the ball rolling. The ZIPs are easily created manually on the file system. No need to set the ZIP extra fields or some manifest entry because the mechanism can detect the property type by file extension. On 30.09.2011 14:04:30 Steele, Richard wrote: > On Tue, Sep 27, 2011 at 11:41 AM, Richard S. Hall <[email protected]>wrote: > > > > > Well, let's see if others are interested in picking it up... > > > > First can someone verify the role of an initial provisioning service in the > OSGi universe? If I'm reading the specification it seems to be a way to > reference, by URL, a zip file that can contain bundles, URLs to bundles, > text, or binary information. This could be used, for example, to bootstrap > an OSGi runtime with an initial set of (optionally) running bundles? > > Rich Jeremias Maerki
