[EMAIL PROTECTED] wrote on 2007-04-11 17:22:25:
> In recent discussion on the felix-dev list, BJ Hargrave wrote¹ of a
> bundle's location string,
>
> > Think of location as a primary key for a Bundle.
>
> If that's the case, then Bundle.update() seems like a strange
> interface. It uses the current location string to fetch a new version
> of the same bundle, or at least a bundle with the same symbolic name.
New version. The document at the URL could be a new version of the bundle.
The management agent which calls update() must "know something" like there
is a new version at that URL. Otherwise why call update()?
>
> But what if the location string -- interpreted as a URL -- resolves to
> a bundle with the /same/ symbolic name and /same/ version? Does that
> just replace the current bundle associated with that location string?
Yes. The framework is deliberately dumb. If she is told to update the
bundle, she does so. Even if the bits are identical.
>
> Or what if the location string resolves to a bundle with a /different/
> symbolic name? Say that bundle {foo, 1.0.0} is installed with a
> location string of "http://localhost/supplyRandomBundle.cgi";, and we
> call Bundle.update(), and the resolved input stream provides bundle
> {bar, 2.3.4}? Does the framework care?
That is totally permissible. The only requirement is that the (BSN,BV)
tuple of the updated bundle is unique within the framework instance.
>
>
> Footnotes:
> ¹
http://www.mail-archive.com/[email protected]/msg04866.html
>
> --
> Steven E. Harris
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> http://www2.osgi.org/mailman/listinfo/osgi-dev
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
