[osgi-dev] Re: Bundle.update() v. BundleContext.installBundle() with a new version

Steven E. Harris seh at panix.com
Wed Apr 18 17:48:01 EDT 2007


"Richard S. Hall" <heavy at ungoverned.org> writes:

> Why can you not just use OBR to install all bundles? If you use OBR
> to deploy the bundles, then it will correctly deal with the case
> where the bundle is already installed...or error if its dependencies
> are not met.

I /am/ intending to use OBR for all these reasons, so I don't really
have an answer to that question. My only point in writing that last
message was to say that if one wants to use OBR, one has to have some
criteria to start with: a bundle symbolic name, or some filter that
can choose Resources from the RepositoryAdmin.

If a server says to a client, "You need to make use of the bundle
located at http://example.com/bundle.jar," that's not enough
information to work with. The client could download the bundle, but
not discern upon trying to install it whether it already existed. The
client wouldn't know what to do upon failure: download it and try to
install it yet again, or carry on as if the bundle was already
installed to begin with. We agree that OBR solves this problem.

The difference I'm trying to point out is that the server can't just
toss a URL at the client. Better is for the server to throw some
bundle selection criteria. I gave the example earlier of making up a
URN namespace:

  urn:osgi-bundle:foo.bar

or

  urn:osgi-bundle:foo.bar:1.0.0

with the first and second URN components under the "osgi-bundle"
namespace corresponding to bundle symbolic name and version. With one
or two pieces of information like that (transmitted as a URI), one can
kick off OBR's installation or update operation.

Do you agree?

-- 
Steven E. Harris


More information about the osgi-dev mailing list