On 11 Apr 2007, at 21:29, Steven E. Harris wrote:
I see no mention in the OSGi R4 specification that precludes two bundles with the same symbolic name but different versions from coexisting as installed in the same framework. In fact, enabling such coexistence seems to be one of the goals of OSGi.
Correct
Still, I'm confused by how one chooses between Bundle.update(), feeding in a new bundle with a new version to replace an existing bundle with the same symbolic name, and BundleContext.installBundle(), also supplying a new bundle with a new version, but leaving a currently installed bundle with the same symbolic name in place.
I think you've answered your own question. Use Bundle.update() when a bundle that is already installed needs to be updated, for example because the bytes on disk for that bundle have changed. Use BundleContext.installBundle() when you have a bundle from a new location that is not already installed in the platform.
My interest is in enabling bundle management in a client that downloads "opaque" bundles from a server. By opaque, I mean that the client doesn't know the symbolic name and version of the bundles it downloads, but would like to install them appropriately -- updating in cases where a bundle with the same symbolic name already exists, and just installing when such a similar bundle is not already installed.
You should not need to care about the symbolic names or versions. If you are installing bundles from new locations (where "location" can be a logical URI rather than a physical URL), then you should use BundleContext.installBundle(). If some of those bundles turn out to have the same symbolic name as an already installed bundle, but with a higher version number, then the normal bundle dependency rules will select the highest version number that falls within the range specified by the importing bundles.
On the other hand if you are scanning your already-installed bundles, then you have the location (from Bundle.getLocation()), which you can pass to the server to get the correct bundle.
Doing this properly seems to rely upon being able to discover the newly downloaded bundle's symbolic name and version /before/ trying to install it, as installing it may clash with an existing bundle, or miss an opportunity to update an existing bundle. Is this goal best delegated to OBR? I see several of these problems solved there, such as figuring out whether an installed bundle is updatable, but I don't think it addresses the problem of not knowing a priori the symbolic name and version of a bundle one wants to install. -- Steven E. Harris _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
